You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Massol <vi...@massol.net> on 2007/03/03 21:36:55 UTC
Re: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT
On Feb 22, 2007, at 8:47 PM, Carlos Sanchez wrote:
> It'd be good to have the tool that checks for API changes between
> versions in the parent pom.
We could try using Clirr for this. The strategy could be something
like http://blogs.codehaus.org/people/vmassol/archives/
think_tank.html#001324_ensuring_binary_compatibility
-Vincent
>
> I agree with John in pushing towards final releases, I already said
> several times that all these alpha/betas are an excuse to make
> dramatic changes while we are actually using them as final.
>
> my 0.02 EUR ;)
>
> On 2/22/07, John Casey <ca...@gmail.com> wrote:
>> How do you mean? What else is there to be concerned about WRT
>> backward
>> compat?
>>
>> BTW, I don't think dropping the method entirely is a good course of
>> action...but we do need to adjust the code to accommodate wagon
>> providers
>> that don't have it.
>>
>> I think the wagon API is probably stable enough to talk about
>> putting out
>> 1.0-final, and then proceed with 1.1-snap development, actually. I
>> don't
>> want to stop forward progress, I just want to make sure we don't
>> get burned.
>> If I caught this particular problem when trying to do a deploy using
>> wagon-webdav, who else would see it? Let's just fix this, and
>> think about
>> how we can setup a couple simple tests for backward compat. I can
>> whip up an
>> integration test project in 3 minutes to test this one...I'll log
>> the jira
>> for it now.
>>
>> -john
>>
>> On 2/22/07, Joakim Erdfelt <jo...@erdfelt.com> wrote:
>> >
>> > The Wagon.getProtocol() method could probably be dropped.
>> > But that won't address the bigger concern. Backwards
>> compatibility.
>> >
>> > - Joakim
>> >
>> > John Casey wrote:
>> > > Also, to be clear, in the past I've broken things massively in
>> Maven and
>> > > other places. Almost without fail, someone has tracked me
>> down, and
>> > > waited
>> > > while I stopped everything I was doing, and fixed the
>> problem...with
>> > > tests,
>> > > if possible.
>> > >
>> > > On 2/22/07, John Casey <ca...@gmail.com> wrote:
>> > >>
>> > >> Just to be clear - did I miss a volley of emails on these
>> topics?
>> > >>
>> > >> -j
>> > >>
>> > >> On 2/22/07, Joakim Erdfelt <joakim@erdfelt.com > wrote:
>> > >> >
>> > >> > The changes to wagon are ... (just to make sure they show
>> in john's
>> > >> > gmail account)
>> > >> >
>> > >> > 1) Timeouts
>> > >> > 2) Streaming Wagon
>> > >> > 3) Limited Transactions
>> > >> >
>> > >> > - Joakim
>> > >> >
>> > >> > John Casey wrote:
>> > >> > > Hi all,
>> > >> > >
>> > >> > > I have something to point out that I think the entire Maven
>> > >> > development
>> > >> > > community needs to hear. I've been doing a lot of work
>> recently
>> > with
>> > >> > > Maven
>> > >> > > trunk, so I notice any (perhaps inevitable) instability
>> that comes
>> > >> > > down the
>> > >> > > pike from dependency APIs. Recently, I've been having a
>> LOT of
>> > >> trouble
>> > >> > in
>> > >> > > this area.
>> > >> > >
>> > >> > > Particularly in the Wagon API. It seems that a change was
>> rolled
>> > >> into
>> > >> > > wagon-provider-api around the beginning of February that
>> introduced
>> > >> > > some new
>> > >> > > methods into the Wagon interface. This is not in itself a
>> problem,
>> > >> > even
>> > >> > > though the current code version is at 1.0-*beta*-3-
>> SNAPSHOT. What
>> > >> > > causes an
>> > >> > > issue is the fact that these new methods are then assumed
>> to be in
>> > >> > > place by
>> > >> > > the new DefaultWagonManager, effectively breaking that
>> manager's
>> > >> > backward
>> > >> > > compatibility with previous releases of Wagon providers.
>> > >> > >
>> > >> > > I tracked all of this down over the course of the past
>> few days, in
>> > >> > > between
>> > >> > > doing the things that I'm actually focused on doing. I
>> can fix this
>> > >> > one
>> > >> > > problem by myself; I'm not pleading for help here.
>> However, I
>> > cannot
>> > >> > > act as
>> > >> > > the gatekeeper for all APIs that get used in Maven trunk,
>> to ensure
>> > >> > their
>> > >> > > stability and backward compatibility. I've been informed
>> that there
>> > >> > > are many
>> > >> > > other such changes heading for Wagon...interestingly
>> enough, a
>> > quick
>> > >> > > search
>> > >> > > of my GMail account doesn't turn up any discussion of
>> these changes
>> > >> > > (unless
>> > >> > > it's buried in the deep past somewhere).
>> > >> > >
>> > >> > > I know that this email can look a bit hypocritical on its
>> face,
>> > >> but I
>> > >> > > really
>> > >> > > do feel that we owe it to our user base to be a little more
>> > >> proactive
>> > >> > in
>> > >> > > ensuring backward compatibility than we have in the past. I
>> > >> understand
>> > >> >
>> > >> > > that
>> > >> > > many Maven developers are on various deadlines, but those
>> > >> deadlines do
>> > >> > > not
>> > >> > > originate in the Maven ASF project, and shouldn't cause
>> undue
>> > >> harm to
>> > >> > the
>> > >> > > community or its code. I'm not trying to say we need to
>> rigidly
>> > >> adopt
>> > >> > and
>> > >> > > conform to some process or other, but we each
>> individually need to
>> > >> > take
>> > >> > > responsibility for discussing and testing any major
>> changes we
>> > >> plan to
>> > >> > > put
>> > >> > > into Maven or its dependencies.
>> > >> > >
>> > >> > > IMHO, pushing new features into a beta API is irresponsible
>> > >> unless you
>> > >> > > can
>> > >> > > be ABSOLUTELY certain it will not impact backward
>> compatibility. In
>> > >> > these
>> > >> > > cases, it is my understanding that the normal practice is to
>> > >> create a
>> > >> > > final
>> > >> > > release of the existing API, and then push these bigger
>> changes
>> > into
>> > >> > the
>> > >> > > next version.
>> > >> > >
>> > >> > > If there's even a shadow of doubt about what effect a
>> change will
>> > >> have
>> > >> > on
>> > >> > > the user community, we need to make a serious effort to
>> start a
>> > >> > > discussion
>> > >> > > about it on this list.
>> > >> > >
>> > >> > >
>> > >> > > Regards,
>> > >> > >
>> > >> > > John
>> > >> > >
>> > >> >
>> > >> >
>> > >> >
>> ---------------------------------------------------------------------
>> > >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> > For additional commands, e-mail: dev-help@maven.apache.org
>> > >> >
>> > >> >
>> > >>
>> > >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT
Posted by Arnaud HERITIER <ah...@gmail.com>.
+1
Arnaud
On 3/3/07, Vincent Massol <vi...@massol.net> wrote:
>
>
> On Feb 22, 2007, at 8:47 PM, Carlos Sanchez wrote:
>
> > It'd be good to have the tool that checks for API changes between
> > versions in the parent pom.
>
> We could try using Clirr for this. The strategy could be something
> like http://blogs.codehaus.org/people/vmassol/archives/
> think_tank.html#001324_ensuring_binary_compatibility
>
> -Vincent
>
> >
> > I agree with John in pushing towards final releases, I already said
> > several times that all these alpha/betas are an excuse to make
> > dramatic changes while we are actually using them as final.
> >
> > my 0.02 EUR ;)
> >
> > On 2/22/07, John Casey <ca...@gmail.com> wrote:
> >> How do you mean? What else is there to be concerned about WRT
> >> backward
> >> compat?
> >>
> >> BTW, I don't think dropping the method entirely is a good course of
> >> action...but we do need to adjust the code to accommodate wagon
> >> providers
> >> that don't have it.
> >>
> >> I think the wagon API is probably stable enough to talk about
> >> putting out
> >> 1.0-final, and then proceed with 1.1-snap development, actually. I
> >> don't
> >> want to stop forward progress, I just want to make sure we don't
> >> get burned.
> >> If I caught this particular problem when trying to do a deploy using
> >> wagon-webdav, who else would see it? Let's just fix this, and
> >> think about
> >> how we can setup a couple simple tests for backward compat. I can
> >> whip up an
> >> integration test project in 3 minutes to test this one...I'll log
> >> the jira
> >> for it now.
> >>
> >> -john
> >>
> >> On 2/22/07, Joakim Erdfelt <jo...@erdfelt.com> wrote:
> >> >
> >> > The Wagon.getProtocol() method could probably be dropped.
> >> > But that won't address the bigger concern. Backwards
> >> compatibility.
> >> >
> >> > - Joakim
> >> >
> >> > John Casey wrote:
> >> > > Also, to be clear, in the past I've broken things massively in
> >> Maven and
> >> > > other places. Almost without fail, someone has tracked me
> >> down, and
> >> > > waited
> >> > > while I stopped everything I was doing, and fixed the
> >> problem...with
> >> > > tests,
> >> > > if possible.
> >> > >
> >> > > On 2/22/07, John Casey <ca...@gmail.com> wrote:
> >> > >>
> >> > >> Just to be clear - did I miss a volley of emails on these
> >> topics?
> >> > >>
> >> > >> -j
> >> > >>
> >> > >> On 2/22/07, Joakim Erdfelt <joakim@erdfelt.com > wrote:
> >> > >> >
> >> > >> > The changes to wagon are ... (just to make sure they show
> >> in john's
> >> > >> > gmail account)
> >> > >> >
> >> > >> > 1) Timeouts
> >> > >> > 2) Streaming Wagon
> >> > >> > 3) Limited Transactions
> >> > >> >
> >> > >> > - Joakim
> >> > >> >
> >> > >> > John Casey wrote:
> >> > >> > > Hi all,
> >> > >> > >
> >> > >> > > I have something to point out that I think the entire Maven
> >> > >> > development
> >> > >> > > community needs to hear. I've been doing a lot of work
> >> recently
> >> > with
> >> > >> > > Maven
> >> > >> > > trunk, so I notice any (perhaps inevitable) instability
> >> that comes
> >> > >> > > down the
> >> > >> > > pike from dependency APIs. Recently, I've been having a
> >> LOT of
> >> > >> trouble
> >> > >> > in
> >> > >> > > this area.
> >> > >> > >
> >> > >> > > Particularly in the Wagon API. It seems that a change was
> >> rolled
> >> > >> into
> >> > >> > > wagon-provider-api around the beginning of February that
> >> introduced
> >> > >> > > some new
> >> > >> > > methods into the Wagon interface. This is not in itself a
> >> problem,
> >> > >> > even
> >> > >> > > though the current code version is at 1.0-*beta*-3-
> >> SNAPSHOT. What
> >> > >> > > causes an
> >> > >> > > issue is the fact that these new methods are then assumed
> >> to be in
> >> > >> > > place by
> >> > >> > > the new DefaultWagonManager, effectively breaking that
> >> manager's
> >> > >> > backward
> >> > >> > > compatibility with previous releases of Wagon providers.
> >> > >> > >
> >> > >> > > I tracked all of this down over the course of the past
> >> few days, in
> >> > >> > > between
> >> > >> > > doing the things that I'm actually focused on doing. I
> >> can fix this
> >> > >> > one
> >> > >> > > problem by myself; I'm not pleading for help here.
> >> However, I
> >> > cannot
> >> > >> > > act as
> >> > >> > > the gatekeeper for all APIs that get used in Maven trunk,
> >> to ensure
> >> > >> > their
> >> > >> > > stability and backward compatibility. I've been informed
> >> that there
> >> > >> > > are many
> >> > >> > > other such changes heading for Wagon...interestingly
> >> enough, a
> >> > quick
> >> > >> > > search
> >> > >> > > of my GMail account doesn't turn up any discussion of
> >> these changes
> >> > >> > > (unless
> >> > >> > > it's buried in the deep past somewhere).
> >> > >> > >
> >> > >> > > I know that this email can look a bit hypocritical on its
> >> face,
> >> > >> but I
> >> > >> > > really
> >> > >> > > do feel that we owe it to our user base to be a little more
> >> > >> proactive
> >> > >> > in
> >> > >> > > ensuring backward compatibility than we have in the past. I
> >> > >> understand
> >> > >> >
> >> > >> > > that
> >> > >> > > many Maven developers are on various deadlines, but those
> >> > >> deadlines do
> >> > >> > > not
> >> > >> > > originate in the Maven ASF project, and shouldn't cause
> >> undue
> >> > >> harm to
> >> > >> > the
> >> > >> > > community or its code. I'm not trying to say we need to
> >> rigidly
> >> > >> adopt
> >> > >> > and
> >> > >> > > conform to some process or other, but we each
> >> individually need to
> >> > >> > take
> >> > >> > > responsibility for discussing and testing any major
> >> changes we
> >> > >> plan to
> >> > >> > > put
> >> > >> > > into Maven or its dependencies.
> >> > >> > >
> >> > >> > > IMHO, pushing new features into a beta API is irresponsible
> >> > >> unless you
> >> > >> > > can
> >> > >> > > be ABSOLUTELY certain it will not impact backward
> >> compatibility. In
> >> > >> > these
> >> > >> > > cases, it is my understanding that the normal practice is to
> >> > >> create a
> >> > >> > > final
> >> > >> > > release of the existing API, and then push these bigger
> >> changes
> >> > into
> >> > >> > the
> >> > >> > > next version.
> >> > >> > >
> >> > >> > > If there's even a shadow of doubt about what effect a
> >> change will
> >> > >> have
> >> > >> > on
> >> > >> > > the user community, we need to make a serious effort to
> >> start a
> >> > >> > > discussion
> >> > >> > > about it on this list.
> >> > >> > >
> >> > >> > >
> >> > >> > > Regards,
> >> > >> > >
> >> > >> > > John
> >> > >> > >
> >> > >> >
> >> > >> >
> >> > >> >
> >> ---------------------------------------------------------------------
> >> > >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> > >> >
> >> > >> >
> >> > >>
> >> > >
> >> >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
> >>
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>