You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <ca...@gmail.com> on 2007/02/22 19:22:47 UTC
Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT
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
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
>
>
Re: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT
Posted by Vincent Massol <vi...@massol.net>.
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 Carlos Sanchez <ca...@apache.org>.
It'd be good to have the tool that checks for API changes between
versions in the parent pom.
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
Re: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT
Posted by John Casey <ca...@gmail.com>.
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
>
>
Re: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
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
Re: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT
Posted by John Casey <ca...@gmail.com>.
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
> >
> >
>
Re: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT
Posted by John Casey <ca...@gmail.com>.
Just to be clear - did I miss a volley of emails on these topics?
-j
On 2/22/07, Joakim Erdfelt <jo...@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
>
>
Re: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Feb 07, at 5:11 PM 22 Feb 07, Joakim Erdfelt wrote:
> Just some thoughts.
>
> I would like to change wagon-webdav's protocol definition.
>
> Currently it is "dav:http://" and "dav:https://" both of which are
> technically invalid protocols.
> It should be "dav://" and "davs://".
>
As long as you support the old ones that are used everywhere.
> I've wanted to make the wagon's register URL handlers for
> themselves too.
What does that mean exactly?
> That would allow for a more natural Streaming Wagon implementation
> too.
>
> - Joakim
>
> Joakim Erdfelt 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
>
>
---------------------------------------------------------------------
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 Joakim Erdfelt <jo...@erdfelt.com>.
Just some thoughts.
I would like to change wagon-webdav's protocol definition.
Currently it is "dav:http://" and "dav:https://" both of which are
technically invalid protocols.
It should be "dav://" and "davs://".
I've wanted to make the wagon's register URL handlers for themselves too.
That would allow for a more natural Streaming Wagon implementation too.
- Joakim
Joakim Erdfelt 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
Re: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
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