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
________________________________________________________________________
|