Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of ralph.goers@dslextreme.com
 designates 209.85.200.170 as permitted sender)
Message-Id: <037B3048-0A0C-4E2E-A705-74015549F42E@dslextreme.com>
From: Ralph Goers <ralph.goers@dslextreme.com>
To: "Commons Developers List" <dev@commons.apache.org>
In-Reply-To: <4A0A026E.6080608@btopenworld.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [all] Rebooting commons projects
Date: Tue, 12 May 2009 16:44:42 -0700
References: <607889.43671.qm@web55106.mail.re4.yahoo.com>
	 <f2e8eedf0905051812w24d8dea6u5a86090311101c99@mail.gmail.com>
	 <gtr9s4$2gc$1@ger.gmane.org>
	 <96C9653C-4445-4B67-AA81-1E1BC9447CF9@dslextreme.com>
	 <4A05F456.8020601@btopenworld.com>
 <31cc37360905091827t88cf01dke8561517c872f069@mail.gmail.com>
 <4A0A026E.6080608@btopenworld.com>


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.

Ralph


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org