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.
Vadim
