Thanks to everyone for the discussion so far. I have looked more closely
at what is actually happening in JIRA and the branches. It seems to me
that the community has been following two different approaches for
managing release ids:
1) The approach followed by 10.1 and 10.2.
2) The approach followed by 10.3 and 10.4.
I prefer the first approach. I would like to summarize its features:
a) Any committer can bump the 4th digit of the release id without
initiating a community discussion. This lets people create new patch
distributions with unique release ids that distinguish them from
community releases.
b) When the release manager publishes a new official release, the 4th
digit of the release id is bumped on the branch. The meaning of the
branch id is "the next (unofficial) patch distribution produced on this
branch." At the same time, a new release id is added to JIRA. The
meaning of this new JIRA release id is "the next official release on
this branch". This release id is even further advanced: its 3rd digit is
bumped.
Here is what I am seeing today:
Branch Latest Official Release Current Release ID on
Branch Highest JIRA (next official) Release ID
10.1 10.1.3.1 10.1.3.3
10.1.4.0
10.2 10.2.2.0 10.2.2.1
10.2.3.0
10.3 10.3.3.0
10.3.3.1 10.3.3.1
10.4 10.4.2.0
10.4.2.1 10.4.2.1
I propose that we adopt (1) as our policy going forward. If the
community agrees, then I propose to bring JIRA's "next" ids for 10.3 and
10.4 into agreement with this policy:
i) rename the next official 10.3 release to be 10.3.4.0
ii) rename the next official 10.4 release to be 10.4.3.0
Here are the practical consequences of this policy for Myrna when she
publishes a 10.5.1.2 release:
iii) she will bump the release id on the 10.5 branch to be 10.5.1.3
iv) she will add a new release id to JIRA: 10.5.2.0
Does this sound OK?
Thanks,
-Rick
