hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestAuthenticator.java TestHttpState.java TestHttps.java TestMethodsExternalHost.java TestWebappBasicAuth.java
Date Sun, 06 Jul 2003 12:24:13 GMT

I understand your position. The problem of maintaining the compatibility
with 2.0 APIs has been discussed several times on this mailing list, and
if my memory does not fail me, the consensus was that it could not be
maintained in the future versions. The existing architecture cannot
evolve, sadly, it has got to be redesigned so it could be 'evolvable' in
the future. HttpClient is in a dire need of a better design. We have
been very explicit about it. 

This said, we will maintain 2.0 branch for those who rely on it, but we
also have obligations to other users as well. Some bug fixes are simply
not possible if existing architecture is to be preserved. 

I hope you will be able to see beyond the interests of your own project.



On Sun, 2003-07-06 at 13:46, Christopher Lenz wrote:
> Oleg,
> Oleg Kalnichevski wrote:
> > It was an unfortunate oversight. The method should have been deprecated
> > along with all other methods whose functionality is now provided by
> > CookieSpec classes. I apologise for that.
> That's what I thought. Please remember to add the @deprecate tag to the 
> 2_0 branch, so that others don't "suffer" from this oversight.
> > We will no longer be able to provide API compatibility with 2.0 branch
> > in CVS HEAD. We have to start fixing things that are broken by design
> Sigh. I hope you're not serious about this. I understand that you need 
> to change stuff, and maybe a lot of stuff. Still, you need to *evolve* 
> the API[1], implying that you should maintain API compatibility with the 
> 2.0 release.
> Now, I can live with deprecated methods being removed inbetween point 
> releases (usually they live a bit longer). The methods were deprecated, 
> and we're not using them anymore.
> I absolutely cannot silently accept this "announcement" that API 
> compatibility is not going to be maintained. HttpClient has already been 
> forked in the past[2] for this reason. Now that HttpClient is a 
> healthier and also pretty successful project, the team should pay utmost 
> attention to not breaking its clients. If changes are necessary, 
> deprecate first and find a good way to evolve the API without breaking 
> it. That can be challenging, but it's usually worth the effort.
> > 2.0 is almost done. We foresee only minor documentation changes in the
> > future. The code will not be touched unless something _really_ bad pops
> > up.
> > 
> > Please use official 2.0.x builds. 
> We will continue to use both: the official releases of the 2.0 branch 
> (and hopefully soon a 2.0 final), as well as CVS HEAD.
> The latter is done because we want to detect potential problems with our 
> usage of HttpClient as early as possible. Obviously, that will make it 
> easier for us to switch to 2.1 (for example) when it's released, but 
> more importantly, we can give feedback to the HttpClient team when stuff 
> changes that we're not happy with.
> Oh wait, there's a Jakarta project about this:
>    http://jakarta.apache.org/gump/
> -chris
>    [1] http://eclipse.org/eclipse/development/java-api-evolution.html
>    [2] 
> http://cvs.apache.org/viewcvs.cgi/jakarta-slide/src/webdav/client/src/org/apache/commons/httpclient/

View raw message