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, 12 May 2009 23:44:42 GMT

On May 12, 2009, at 4:12 PM, Stephen Colebourne wrote:
> Every so often, projects need to "reboot". Its healthy and useful,  
> as most developers want innovate rather than maintain.
> Up until now, we've tried to do this within the existing project.  
> Its failed miserably.
> So, lets just accept that some projects need a clean slate, with  
> fresh ideas, people and energy. And no restrictions. So, the  
> concepts of [lang], [collections] and [beanutils] live on, but in  
> new implementations.
> The new stuff might re-use old code. or it might not.
> It will definitely have a new package name.
> And the new stuff should be a new parallel project in commons. And  
> yes, logically, they should start in the sandbox.
> Lets also say that the new project name cannot be numerically based,  
> so no [lang2] or [lang5] projects, thats way too confusing. But  
> [lang-ng] would be ok.
> Obviously then, the trunk of [lang], [collections] and similar then  
> remain based on the stable codebase. Bug fixes only. No backwards  
> incompatible changes.
> And once project [xyz-ng] is released, then [xyz] can have its  
> website updated to indicate that there is a potential replacement.
> This is a simple approach, and I think it will work if we buy into it.
> Are we willing to try it? Starting with [lang] and [collections]?
I appreciate the sentiment of this but I don't agree with the way you  
are approaching it.

It would make sense to me to say "The new minimum version is JDK 1.5"  
and then create a new commons "main project" (i.e. a sibling directory  
to "proper") where everything under it was jdk 1.5. I don't agree that  
everything should go to sandbox.

If that approach isn't taken then it makes much more sense to create  
new branches in the individual projects to do the work. Why would I  
look for lang-ng in sandbox? I also don't like the "-ng". In a way, I  
prefer what configuration has done with experimental-configuration2,  
although I'm not convinced the "2" business is the right solution  
either. At some point I would expect that the current trunk would be  
renamed to config-1.x and experimental-configuration2 would be renamed  
to trunk.


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

View raw message