>
> -----Original Message-----
> From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 28, 2001 12:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [httpclient][VOTE] going forward
>
>
>
> ----- Original Message -----
> From: "Remy Maucherat" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, August 28, 2001 11:14 AM
> 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.
> >
> > 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.
> >
> > Remy
>
> I don't see anything in the proposal preventing this. As the maintainer,
> you can make as many or as few changes to the 1.x branch as you like. It
> seems like most people are interested in the 2.0 design, but Slide clearly
> needs the 1.0 interface, since it is exposed by the API. Vincent's proposal
> seems like a very reasonable compromise.
>
> - Morgan
>
>
i don't really agree with a major release number being assigned to a buggy implementation, but if this is the compromise that must be made, let's go ahead and do it.
+1
-doug
