hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject RE: Next Release? What about next release version number?
Date Thu, 08 Jan 2004 14:21:38 GMT
Eric,
I find it hard to disagree with you, being a fan of incremental, iterative development myself.
I just regret all the energy and time that went into 2.0 API compatibility workarounds so
far. If we go with 3.0 then I would like to see a few more 2.0 API breakages that had been
turned down for the sake of maintaining 2.0 compatibility, especially in the exception handling
framework. I would also suggest HttpMethod interface be completely gotten rid of and the abstract
HttpMethodBase renamed to HttpMethod. 

Oleg

-----Original Message-----
From: Eric Johnson [mailto:eric@tibco.com]
Sent: Thursday, January 08, 2004 14:53
To: Commons HttpClient Project
Subject: Re: Next Release? What about next release version number?


Oleg,

I understand your thinking, but my thinking it is that it is far more 
important to release new stable releases often, rather than worrying 
about their version number.  Re-exposing my bias, I strongly prefer 
incremental change.  With many compliments to the incredible work that 
has gone into the next release so far (the presumed 2.1, now 3.0?), I 
don't see any reason to hesitate calling it 3.0.  At the same time, I 
don't think that means that we should consider jumping on radical 
changes beyond what has been done already.  The version number tells me 
that it is not going to be a drop-in compatible change, but the small 
number of API changes is actually a good thing, in that clients can 
migrate quickly.

My previous comment was there only to prod for consideration of low 
impact changes that might make it easier to maintain HttpClient moving 
forward.

For example, the one change that occurs to me - get rid of the illusion 
(delusion?) that clients could *ever* successfully implement the 
HttpMethod interface.  Perhaps deprecate the interface, and override it 
with an abstract base class, which clients would be expected to override 
instead.  This isn't a huge change, and adds no additional 
functionality, but adds a lot of flexibility for enabling backward 
compatible enhancements.

-Eric.

Kalnichevski, Oleg wrote:

>>Thinking about it as a 3.0 release, though, I think we should make an 
>>effort to change the 3.0 API so that we're more confident of our ability 
>>to make critical incremental changes.  
>>    
>>
>
>I hate revisiting the same discussions that raged on this forum 6 months ago, but this
is exactly the point. If we decide to go 3.0, then we should stop playing 'bend 2.0 API around'
kind of games and should get down to some serious work (which would  inevitably delay the
next stable by maaaaaany months, if not years, judging by our current rate of progress)
>
>Oleg 
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


---------------------------------------------------------------------
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