> > > > Just a recomendation that you should feel free to ignore if you feel
> > like
> > > ;)
> > > >
> > > > However I would suggest not doing a release and not changing slide
> just
> > > yet.
> > > > Why? Because that means that you are releasing software that you
know
> > you
> > > > wont be supporting in future, and has many bugs. Instead just
refactor
> > it
> > > > completely and nicely.
> > > >
> > > > Then in the future have slide change *once* rather than twice and
> > > preferably
> > > > provide adapter classes to bridge between two APIs. Remember users
who
> > > have
> > > > to suffer through a changing API are less likely to come back and
IMHO
> > it
> > > is
> > > > better NOT to release something you know is buggy and you know you
> will
> > > not
> > > > be supporting.
> > > >
> > >
> > > Peter,
> > >
> > > I agree with what you say. That's even what Rod and I were previously
> > > suggesting. However, we don't want to let Slide committers down and it
> > seems
> > > they really want to push for a 1.0 release that is exactly their code
> base
> > > (no API refactoring). If this is what it takes to make everyone happy
> and
> > > they can contribute to the projet I am all for it. Now, if Slide
> > committers
> > > are happy to keep their own httpclient version (the 1.0 of the
> > proposition)
> > > for the time and agree to help and consider moving to
commons-httpclient
> > 1.0
> > > (the 2.0 of the proposition) if it brings nice improvements, then I am
> > even
> > > more for that ! I was just led to believe that this is no what they
> wanted
> > > from the last batch of emails. I just don't want to alienate anyone
:-)
> > >
> > > I do think that your recommandation makes the most sense :)
> >
> > Vincent,
> >
> > Your proposal is not accurate, as it is possible to fix bugs and do what
> is
> > needed without breaking the API compatibility, except for a few very
minor
> > details.
> > So please, don't say : "it's not possible to do anything without Rod's
> > refactoring", as it's simply not true (of course, I think that's what he
> > would want you to believe).
> >
> > For example, you can add multivalued headers by adding
> > addHeader/removeHeader to HttpMethod. That won't break binary
> compatibility
> > in most cases (at least for people who used the abstract class). I don't
> > why, but there seems to be the idea that you can't implement headers
with
> > multiple values with the original HTTP client, which is 100% wrong.
> >
> > So the problems mentioned will also get fixed by the 1.x branch (except
> > without breaking API compatibility in any significant way).
> >
>
> I believe you are right. However what I was saying was to have a 1.0
release
> that is the code from Slide and not make a lot of changes and bux fixes
> before releasing it. That would be 1.1. Why ? Because we would like to
work
> ASAP on the main 2.0 branch. Also the idea is that, with everyone's help,
> Slide uses the 2.0 version when it is ready. If your idea is to continue
> working on the 1.x branch and make changes there then I don't think it is
a
> good idea and I completely second Peter in that case. Should that be what
> you wish, then you should probably continue to use the httpclient you have
> in Slide and work on it from there. We would work on 1.0 for
> commons-httpclient and maybe one day you'll want to use commons-httpclient
> and do the migration.
>
> Tell us where you stand. If I understood correctly your last email you
would
> want to maintain 2 branches : a 1.x and a 2.x. This is what I don't like.
I
> agree to having a stable 1.0 and just making bug corrections. However
> everything new, API modifications, ... should go in the 2.0 branch.
However,
> bear in mind that we can argue on a point by point to Rod's refactoring if
> you wish but API stability should not be the keyword for the 2.x branch.
>
> I'm trying to accomodate everyone ... Please help me out.
Then case closed, we fork.
For example, at some point, we'll want to add some new features, like DIGEST
support, without having to update to 2.0 at the same time.
Remy
