hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <cml...@gmx.de>
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 11:46:00 GMT

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:


   [1] http://eclipse.org/eclipse/development/java-api-evolution.html

Christopher Lenz
/=/ cmlenz at gmx.de

View raw message