commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [all] Rebooting commons projects
Date Mon, 18 May 2009 06:39:09 GMT
On Sun, May 17, 2009 at 11:29 PM, Ralph Goers
<> wrote:
> On May 17, 2009, at 3:16 PM, Stephen Colebourne wrote:
>> Matt Benson wrote:
>>> Or, to put it another way, the consensus seems to be
>> > that the component + the major version # makes a "project."
>> As I've said before, I won't try and stop this, I no longer have the moral
>> rights here. I do believe that this approach is profoundly wrong however.
>> Consider an analagous case - Tapestry. Each major version of Tapestry is
>> known, with derision, as being extremely different to the previous. This is
>> to the extent that I, and I'm pretty sure many, many others wouldn't touch
>> Tapestry with a barge pole now simply because we can't rely on it not being
>> reinvented all the time.
>> A project name does imply something important about compatibility even
>> across major versions in my book.
>> For example, if I do release Joda-Time it will simply be a version with
>> the deprecated methods removed, and maybe a few edge cases tweaked. Its the
>> classic commons type library (even though its not in commons). Imagine the
>> chaos and confusion if I were to declare the 'rebooted' jsr-310 as Joda-Time
>> 2. Unthinkable. Yet, that is exactly what is being proposed here.
> Why would that be unthinkable? OTOH, if it becomes part of the JDK I guess
> there is no point for a Joda Time 2.
> The only time it is unthinkable is if the API changes so that old
> applications can't use it without code changes AND the package names stay
> the same. It serves no useful purpose, other than to confuse everyone, to
> have commons-lang in proper and commons-lang-ng in the sandbox. OTOH, having
> a package name like org.apache.commons.lang2 makes it quite clear it isn't
> compatible with the current release.
> I think a great example is httpclient. It used to be part of commons. Then
> it moved off to its own high level project. But if you go to
> you will find a version that is very different than what most people are
> still using - version 3 (that might be because the main web site has been
> for version 4 for quite a while but the formal release only happened in
> February). Trying to actually find version 3 is a bit of an adventure as it
> is buried away under oac..But the bottom line is, Version 4 is not API
> compatible with Version 3.  The same thing is true of Apache Maven 1 vs
> Maven 2.

HttpClient is another example that is complained about by users :) The
only saving grace of v4 is that it is now named HttpComponents Core
(fitting Stephen's suggestion of a new name).

Of course that means users are also confused due to change in brand
and complaining about that. Should they use HttpComponents?
HttpClient? 6 of 1 etc.


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

View raw message