Return-Path: Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list commons-httpclient-dev@jakarta.apache.org Received: (qmail 24486 invoked from network); 16 Jul 2003 14:27:10 -0000 Received: from mxout4.cac.washington.edu (140.142.33.19) by daedalus.apache.org with SMTP; 16 Jul 2003 14:27:10 -0000 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h6GERBCK001135 for ; Wed, 16 Jul 2003 07:27:11 -0700 Received: from u.washington.edu (ss07.co.us.ibm.com [32.97.110.72]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h6GERA49031275 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 16 Jul 2003 07:27:11 -0700 Message-ID: <3F156092.1070708@u.washington.edu> Date: Wed, 16 Jul 2003 10:26:26 -0400 From: Michael Becke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030313 Minotaur/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Commons HttpClient Project Subject: Re: [VOTE] Add commons-codec as an HttpClient dependency References: <825BF35A92B3F0479CC164ECBBE9376E0DE5BD@kccxoex06.corp.kpmgconsulting.com> In-Reply-To: <825BF35A92B3F0479CC164ECBBE9376E0DE5BD@kccxoex06.corp.kpmgconsulting.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Kalnichevski, Oleg wrote: > Right, but the problem is those folks who use CVS snapshots while > insisting on complete (maximum) API compatibility with 2.0 branch. > They have not been quite receptive to 'but it was part of our plan > for 2.1' kind of arguments up to now. > > Of course, I can put up the same 'Evil Comrade' act as always, but I > have a feeling that some of them did not quite appreciate my sarcasm. No need to resort to the 'Evil Comrade'. I have been looking into standard versioning techniques in order to get some perspective on this. On the positive side, it seems that for a minor release (what we are doing) it is okay to add an external dependency. So, if we ever plan to add codec we might as well do it now. On the negative side, we are supposed to be making only external-interface-compatible changes. In general this has been our goal, but we have removed some deprecated methods which is a no-no. We may also have some difficulty with this when it comes to redirects. This makes we wonder if our plans for 2.1 are compatible with a minor release. Granted we can bend the rules a little with the consensus of HttpClient users but I want to keep from going too far. I suggest we consider resurrecting the removed deprecated code (ever though it was nasty and I am glad it is gone). I also think we should start looking closely at how we will accomplish our plan to move redirect/retry logic to HttpClient. Mike