hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@digitalinsight.com>
Subject RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/com mons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java Tes tMethodsExternalHost.javaTestWebappBasicAuth.java
Date Mon, 07 Jul 2003 00:46:30 GMT
My 2 cents.

It is ALWAYS possible to maintain binary compatibility.  The downside is
that it is ugly and gets unmaintainable over time and it occasionally forces
you to create new classes or methods where you would have liked to have
reuse the old name. Such is life.

An acceptable compromise is to maintain deprecated methods and classes for a
release or two and then remove them.


-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Sunday, July 06, 2003 2:33 PM
To: Commons HttpClient Project
Subject: RE: cvscommit:

I have a feeling that you somehow suspect me of waking up this morning
and thinking: "Geez, I feel like screwing up those HttpClient APIs.
Wouldn't that be fun?". Believe me, I am not THAT bad

Please allow me to copy verbatim the paragraph from the release plan
that I wrote:


The objective of the 2.1 release of HttpClient is to build upon the
foundation laid with the previous release while addressing those 
architectural shortcomings and flaws identified during 2.0 development
process. Several well known and much complained about problems could not
be resolved without sacrificing API stability. The primary motivation
behind the 2.1 is to fix those design limitations, breaking 2.0 API
compatibility where absolutely unavoidable, while preserving overall
compatibility with 2.0 use patterns. 

Cmon, what else am I supposed to say to make you beleive?

And of course, it just goes without saying that each and every patch
will be discussed on this mailing list and committed only if there are
enough confidence that it satisfies the above stated criteria. You are
welcome to dispute the merits of each individual API breakage, but just
demanding 100% compatibility with 2.0 release no matter what will
effectively halt further development of HttpClient.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message