hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <cml...@gmx.de>
Subject Re: [PATCH] You see, it did not even hurt [no more disk buffering in GetMethod]
Date Fri, 24 Jan 2003 12:17:40 GMT
Kalnichevski, Oleg wrote:
> Chris
> 
> I see your point. However, let me reiterate a few points that I deem important too. 
> 
> It's not just about clean API. The code we would like to deprecate contains bugs. I personally
see no sense in fixing stuff that does not make sense.  I see removal of that code as a lesser
evil compared to releasing buggy code

Just deprecate it and say it is buggy in the Javadocs. Then API clients 
will have a chance to migrate their code before their builds fail.

Deprecation is all about informing users about parts of the code that 
may not work correctly, will not me fixed/maintained and will probably 
be removed in one of the following releases.

-chris

> Oleg
> 
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: Friday, January 24, 2003 12:25
> To: Commons HttpClient Project
> Subject: Re: [PATCH] You see, it did not even hurt [no more disk
> buffering in GetMethod]
> 
> 
> Ortwin and all,
> 
> in a continuous-integration world (http://jakarta.apache.org/gump/), 
> backwards compatibility doesn't only matter between releases. The last 
> release of HttpClient is so very very outdated, that many API clients 
> are currently forced to use CVS HEAD. And that has been quite a 
> challenge in the past, due to sudden API-breaking changes without much 
> of a warning.
> 
> Why does it hurt to deprecate instead of remove? Just because you want a 
> clean API? We don't need a perfect API, but one that is reliable and 
> stable (and *released* ;-) ). Deprecation is a good way to evolve an API 
> towards perfection, while continuously breaking an API and delaying a 
> release for always a couple more this to clean up will frustrate the API 
> users.
> 
> I very much appreciate the work you're all doing on HttpClient, but 
> please "ship" the bastard and start doing API evolution instead of 
> revolution.
> 
> -chris
> 
> Ortwin Gl├╝ck wrote:
> 
>>One more argument towards complete removal instead of just deprecation: 
>>do we really care about backwards-compatibility? I mean HttpClient's 
>>outer interfaces have changed *radically* since the last release. So 
>>existing apps need to be re-integrated anyway!



Mime
View raw message