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 Tue, 19 May 2009 02:51:05 GMT

On May 18, 2009, at 6:10 PM, Stephen Colebourne wrote:

> As a minimum, major changes require a package name change, and as  
> has been pointed out a maven id change.
> So:
> (1) minor incompatible changes (remove long deprecated methods or  
> fix details at the edges). These are compatible for 99% of users and  
> can be a major version (or perhaps minor) with no package or maven  
> name change.
> (2) major incompatible changes (moving classes between packages,  
> changing how the code is used, anything that causes the user to need  
> to reread docs, inability to use new version as a dependency for  
> something compiled using old version). These can be thought of as a  
> major version change with associated package name change and maven  
> name change.
> (3) major reboot (same problem space, but lots of rewrite), I'd  
> still strongly prefer to see these in the sandbox (eg cli2).  
> Socially, they are often a different set of committers with a subtly  
> different set of design ideas (all good things). Although the  
> sandbox approach is preferable, my minimum requirement however is a  
> major version change with package name change and maven name change.
> Hopefully, each set of changes can be classified into one of those  
> three groups. However, IMO [collections] and [cli] are both cases  
> that would have been better off taking the sandbox route.
> Personally I'm surprised that the sandbox route isn't more popular  
> as it allows proper innovation with no limits (ie. no one like me  
> looking over the shoulder...). Maybe, its a fear of difficulty in  
> getting it promoted. Maybe its a desire to retain the brand name of  
> the original. Maybe a separate thread should identify the fears.
What is going on with commons configuration is a great example.  
experimental-configuration2 won't be completely API compatible but  
will be somewhat. It will require and take advantage of Java 5  
features.  It isn't clear yet whether this will be a 2) or a 3)  
(probably somewhere in between). What is clear is that any time a  
patch is made to trunk the same patch is also applied, when possible,  
to the experimental branch. As unit tests are added to trunk they are  
also added to the experimental branch if they can be. If this work was  
going on in sandbox it would, IMO, be far more likely that the sandbox  
would get out of synch with the "production" version. And why bother  
working in sandbox when we can just collaborate on a branch?


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

View raw message