Morgan Delagrange wrote:
> Unfortunately I agree with Rod about the API. We're
> trying not to tear up track, but it's an unreleased
> component nonetheless. Once it's released, it will
> enter the normal cycle of major releases/minor
> releases/bug fixes that are supposed to give good
> choices of features vs. stability. Right now it's a
> beta, and it should only take a majority decision to
> make changes.
If this is the case I can only say that I'll then must fork the HttpClient
code,
I need a stable/working version... period.
If it can't be in the commons then in the slide cvs or otherwise a private
copy but an unstable version that can break code compatibility or even
functionality, that is something I do not want to work with.
I'm the first to change / improve things but only when I know it doesn't
hurt other people.
For example I wanted to change the security interface of slide but Remy said
it needed to wait until the next major release, fine with me, now I'm using
a forked local copy to develop that part and later I will merge it or
discard it whatever is best. I have also code from my previous fork (before
I was a committer) that didn't get integrated because I felt it was not good
enough (most of it went in). I'm still maintaining applications written
using that forked version. Maintaining a stable version of HttpClient will
be a piece of cake.
My point is, you need to consider your clients or otherwise they will
abandon you.
If you want to do major changes please take the version from a couple of
weeks ago label it
as a stable version and then the slide team can use that to work with and
after your major changes
we can use your next stable release just like we use other external
libraries.
Dirk
