Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Date: Sun, 6 Jul 2003 14:27:39 -0400
Subject: Re: cvs
 commit:	jakarta-commons/httpclient/src/test/org/apache/commons/httpclient
 TestAuthenticator.java TestHttpState.java
 TestHttps.java	TestMethodsExternalHost.java TestWebappBasicAuth.java
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Michael Becke <becke@u.washington.edu>
To: "Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F080BF8.7050702@gmx.de>
Message-Id: <8677CC77-AFDF-11D7-978B-00306557E112@u.washington.edu>

Just a few comments.

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:  
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:  
> commons-httpclient-dev-help@jakarta.apache.org
>