hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
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:39:13 GMT


> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 06 July 2003 13:46
> To: Commons HttpClient Project
> Subject: Re: cvs commit: jakarta-
> commons/httpclient/src/test/org/apache/commons/httpclient
> TestAuthenticator.java TestHttpState.java TestHttps.java
> TestMethodsExternalHost.java TestWebappBasicAuth.java
> 
> 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.

Strong +1

Please do not break compatibility at once, go through a deprecation
mechanism.

Thanks
-Vincent

> 
> > 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/
> 
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-
> unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-
> help@jakarta.apache.org



Mime
View raw message