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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >>
> >> Just to be clear - did I miss a volley of emails on these
topics?
> >>
> >> -j
> >>
> >> On 2/22/07, Joakim Erdfelt <[EMAIL PROTECTED] > 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: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >>
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
