> I have counted the votes :
>
> Morgan, +1 for option C
> Scott, +1 for option C
> Doug, +1 for option C
> Rodney, +1 for option C
> Remy, +1 for option C
> Vincent, +1 for option C
> Dirk ?
>
> To summarize option C:
>
> * Release a 1.0 version of httpclient which is 100% compatible with Slide
> (it is actually the code that was given by Slide to commons httpclient +
> maybe a few changes but no API changes, no new logging mechanism). Scott
is
> ok to be the release manager and a release should be done ASAP, possibly
in
> the 1 or 2 coming weeks.

I have a version of the source which is a snapshot of HTTP client without
the added logging features, so I can do that.
There may be a few patches which will be lost in the process, and we'll need
to reapply them later (plus also merge some of the bugfix oriented patches
which went into the branch).

> * Tag a 1.x branch in CVS.  The 1.x branch would be focused on keeping API
> compatibility with Slide and all Slide users who are already using
> httpclient. Changes are of course allowed to the 1.x branch, especially
bug
> fixes but also changes needed by Slide before it can move to the 2.x
branch
> (see below).
>
> * Work on the 2.x release on the main CVS branch. We will merge the
> rlwrefactoring branch made by Rod in the main trunk, ensuring that
everyone
> is happy with the refactoring changes and calling for votes if need be.
> However it should be noted that the goal of the 2.x branch is not to keep
> API compatibility but rather to refactor httpclient. Indeed, initially
> httpclient in Slide was not developed to ge a general and generic client
but
> more to fit the needs of Slide. As we now move this component in
> jakarta-commons, it should be as generic as possible (we cannot presume of
> its uses) and 100% compliant with RFCs.
>
> * Help Slide to migrate to version 2.x in sync with Slide's own releases.

+1.

Unless 2.x is really binary compatible, it is unlikely that we'll upgrade
before the next major version of Slide, though (so we will probably upgrade
to 3.x or 4.x instead).

> In summary it seels to me we have found a common ground ... :-) ! Hoorah
...
>
> Now, let's make this a reality.
> Can everyone help Scott perform the 1.0 release. If we all help, I'm sure
we
> can release it very soon and then proceed quickly to the 2.x version on
the
> main trunk *and* to known bug fixing for release 1.1.

Remy

Reply via email to