commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [all] Rebooting commons projects
Date Mon, 18 May 2009 06:29:34 GMT

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.


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

View raw message