Reinhard Pötz wrote:
> Vadim Gritsenko wrote:
>> On Aug 4, 2008, at 3:01 PM, Carsten Ziegeler wrote:
>>
>>> solprovider@apache.org wrote:
>>>> Pick a number that will never be production for the experimental
>>>> branch e.g. 2.7.  Skip a few numbers in case trunk needs another minor
>>>> number (e.g. 2.3 and 2.4) and to avoid confusion that this branch is
>>>> not the immediate successor to 2.2.  Do not use 2.9 in case a
>>>> non-Corona pre-release branch is needed before 3.0.
>>>> A number both distinguishes code compatibility and suggests the
>>>> position in history better than a code name such as x.
>>>> "cocoon-2.7-pipeline" is obviously not compatible with Cocoon-2.2 or
>>>> Cocoon-3.0.  This also handles all possible futures:
>>>> - The number suggests that the code becomes obsolete after 3.0 is
>>>> released if the branch becomes 3.0 or is abandoned;
>>>> cocoon-x-pipeline-1.0 does not.
>>>> - The branch could become NewName-1.0 if the projects split.
>>>> The Lenya project did this twice:
>>>> - Production 1.2 branched to 1.4 for development of 2.0.
>>>> - An experimental branch based on 1.2 incompatible with 1.4 was 
>>>> named 1.3.
>>>>
>>> This sounds to me as the most pragmatic and simplest solution.
>>>
>>> We could start with version 2.7
>>
>> Too complicated / confusing. I'd rather have us use 3.0, and if that 
>> does not work out, we can skip that and start 4.0. It worked fine for 
>> Tomcat, can work for us too.
> 
> You guys have finally convinced me. Let's use 3.0.x for Corona, clearly 
> state that it is alpha software on the website in the README.txt of each 
> release artifact and see what's happening.
> 
> Then we only need to find a package name that isn't used in trunk 
> because Corona should run in parallel with Cocoon 2.2 without a problem 
> (haven't tried it yet but at least in theory).
> 
> The simplest solution would be keeping 'corona' as part of the package 
> name (org.apache.cocoon.corona). IIRC Tomcat also kept the 'catalina' 
> package names.
> 
> Any other suggestions?

I forgot to mention that we also have to find unique Maven artifact IDs 
for the reasons explained above.

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                          http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________