RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java
Christopher, this thread has gotten a bit out of hand now... As long as we manage behaving as mature people, I see no problem in talking things through offensive, implying that we're doing something weird by using CVS HEAD of HttpClient (which is totally normal at Jakarta). And your comment about API compatibility sounded like you don't care very much about preserving compatibility. I apologize if my response sounded harsh to you. Allow me to point out, though, the problems of maintaining 2.0 API compatibility have been discussed repeatedly on this mailing list before, and the decision has been taken BY THE HTTPCLIENT COMMUNITY AS EARLY AS FEBRUARY that maintaining 2.0 compatibility was not feasible due to limitations of the existing architecture. It was a very hard decision and it has not been taken lightly. I believe there was nothing that precluded you from taking part in that decision making process and influencing its outcome. But once the decision has been taken, I do find it a bit irresponsible, to come up with (what I see as) demands to change the course of HttpClient development that suits best your particular project. We have been very explicit about API compatibility issue MONTHS IN ADVANCE: there's a 2.0 branch which will provide you with FULL API compatibility, and you will have our full support migrating to 2.1 once is its APIs are frozen, but further development of HttpClient is not possible without limited API changes in the 2.1 branch. There is a *huge* difference between we should make all possible efforts to keep API compatibility (Michael) and we will no longer be able to provide API compatibility (Oleg). And the difference might not even be technical ;-) I have always been a bad guy of HttpClient community ;-) And will remain a bad guy as long people are not willing to listen to their counterparts' arguments Cheers Evil Comrade Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java
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. Ralph -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Sunday, July 06, 2003 2:33 PM To: Commons HttpClient Project Subject: RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAut henticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java Vincent, 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: -- Objective: 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. Cheers 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]
