Reinhard Pötz wrote:
Vadim Gritsenko wrote:
On Aug 4, 2008, at 3:01 PM, Carsten Ziegeler wrote:
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
________________________________________________________________________
