The current plans for 2.1 are fairly modest and most of the changes can be made with little or no API modifications. The exceptions are:
Taken from <http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/ RELEASE_PLAN_2_1.txt?rev=1.1&content-type=text/vnd.viewcvs-markup>
- Removal of functions & classes deprecated in 2.0.
This one is obvious and I think we can agree this is okay. The one exception is the oversight in Cookie.parse() but that will be fixed.
-Better exception handling framework (Bug #19868).
This one is being debated now. I think this change can be done without API problems, though that is perhaps not the cleanest option.
- Cross-site redirect fix. Authentication, redirect & retry logic to be moved from HttpMethodBase to HttpClient (Bug #20089, #16729).
This is the big one. This fix is the most requested and the most useful I think. This change does not effect method signatures but it does change current Method behavior.
My feeling is that we should make all possible efforts to keep API compatibility. I do not think this is our highest priority though. When it comes between adding 2.1 functionality and API compatibility I think we should choose 2.1 functionality. I think we need to weigh the added benefit to users of new functionality against the burden of not having the functionality because of API compatibility.
Perhaps this debate should occur on a case by case basis. In doing so I think it is quite possible we will come up with a solution for each case that is satisfactory to both "sides".
Mike
On Sunday, July 6, 2003, at 07:46 AM, Christopher Lenz wrote:
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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
