Here is what I got from the thread and think makes a lot of sense.
Working copies of versions in branches would be branches/n.n. This would be the effective trunk for
any version work.
When the team has decided that work is done and the release process begins the branches/n.n would be
*copied* to branches/n.n.0 and the release work would be completed there.
At the time of the copy two changes would occur:
1. In branches/n.n.0 the version number would be changed from n.n-SNAPSHOT to
n.n.
2. In branches/n.n the version number would be changed to n.n.n-SNAPSHOT. The plugin numbers would
be increased.
The new branches/n.n would then allow people to work on the next set of changes
(ostensibly bug fixes).
The release manager would maintain responsibility for branches/n.n.0.
After the release is voted and approved the branches/n.n.0 would be moved to
tags/n.n.0.
I would expect that it is totally acceptable to build the final release from branches/n.n.0 and not
have to rebuild once its has been moved to tags/n.n.0 as tags/n.n.0 is branches/n.n.0 and has simply
been moved.
I think this is the summary of the discussion and based on having released Geronimo twice this is
way better than what we are doing now.
The remaining question is when a release is being completed off of trunk. When this occurs do we
make a branches/n.n *AND* a branches/n.n.0 at the same time and apply versions n.n.n-SNAPSHOT and
n.n respectively?
Not trying to be nitpicky but its going to happen and since we're on the subject we can close the
loop here.
After people's comments we can take a vote if we think we need one and I'll update the release
management section in our wiki with this information so the next set of people on the project will
have it at their disposal.
Aaron Mulder wrote:
Now we only have a 1.0 branch and a dead-1.2 branch? What's going on?
Thanks,
Aaron
