----- Original Message -----
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 28, 2001 5:14 PM
Subject: Re: [httpclient][VOTE] going forward
> > > > > Step 2 : Create a 1.x branch so that bug corrections (but no new
> > > features)
> > > > > can continue to be made for 1.x versions.
> > > >
> > > > +1.
> > >
> > > I made a mistake when casting my vote there, if the "no new features"
is
> > > interpreted strictly, in which case I would vote -1.
> > >
> >
> > No, it should not be interpreted strictly, well not 100% strictly but
> maybe
> > 90% ... :) My only concern is to have 2 branches that will live
> > independently with different sets of committers and not point of
> > convergence ... I don't think it would do any good, would it ? Everyone
> > would be happy but it would be the same as having 2 separate
> > implementations. However if the changes to 1.x are bug fixes and maybe
> some
> > minor evolutions but with the goal of easing the migration to the 2.0
> > release, then I would be for it. Branches are meant to be reconciled ...
> >
> > Your example of adding a DIGEST support in branch 1.x is fine I think
> during
> > the migration phase to 2.0 (i.e. during the time when Slide is still
using
> > 1.x and has not yet migrated to 2.x) but this change should also be
added
> to
> > the main 2. x branch.
> >
> > > Remy
> >
> > P.S.: I have probably come too strong in my other email ... and I
> apologize
> > for that (I should not write emails in the afternoon, I'm too tired ...
> > :-) ).
> >
> > I guess we agree here and the only remaining point is the location of
the
> > 2.x branch. I would not want to see in the sandbox. What about others ?
>
> As 2.0 was never voted upon, this is not up for anyone to decide. It has
to
> be in the sandbox, period.
>
I have said what I think on the subject in another email I just sent. Let's
wait and see what others think.
> Also, I just can't accept your proposal, since Slide is on a different
> schedule than the fast tracked HTTP client. People using the Slide WebDAV
> client are in fact using the HTTP client underneath. Changing its API
would
> introduce API changes to the WebDAV part too. So the move to 2.0 would
only
> happen in Slide 2.0, which isn't even planned yet (that probably means
more
> than a year). So to meet our needs, we have to mantain the 1.x branch for
a
> while, and that probably means there would be a few feature additions in
the
> meantime.
>
Hum ... this is a problem ... one year is a long time ... But isn't it
possible that the WebDAV API would act as a wrapper around
commons-HttpClient-2.x and hide the API changes there ? You said yourself
that it is possible to accomodate for the majority of the changes without
breaking the existing API ...
> Remy
-Vincent
