As far as the use of HttpClient within my company, calling it 2.X would be misleading in that it is not a drop-in enhancement over the 2.0 version. If it is called 2.X, I'd be in the position of having to tell others not to use it, in spite of the version number.
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. Who am I to talk, though? I've not been contributing much lately....
-Eric.
Kalnichevski, Oleg wrote:
Folks,
Before we can start articulating our further plans, there's one important decision to be made which cannot be put off any longer. We have to decide on the next release number.
I am afraid with all the recent changes (new preference architecture, HttpMethodDirector, better exception handling framework, saner authentication code, Commons-Codec, and much more) we can no longer consider the development version of HttpClient a minor release. Version 2.1 would no longer be appropriate, I fear. Too much has changed, even though the HttpMethod interface, the hallmark of 2.0 API architectural ugliness, is still there. Yet, version 3.0 is so tightly associated in my mind with the much talked about complete API overhaul, that I am hesitant to simply move one major version ahead with the current release, leaving the API redesign for 4.0.
I personally tend to lean towards calling the next release 2.5. It is unconventional, but, I feel, best reflects the magnitude of change in HttpClient code.
What do you think?
Oleg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
