Hi Bryan,
This is what I think you should do:
1) Create a 10.14.0.0 release id to represent the head of the
development trunk after you have cut the 10.13 branch.
2) RENAME 10.13.0.0 to be 10.13.1.0. This will automagically associate
the release with all bugs which have been fixed for 10.13.
3) Create a new 10.13.1.1 release id to represent the head of the 10.13
branch after the release goes GA.
Note that you have to adjust the 10.13 ids every time you create a new
release candidate. But the idea is that, when the release is finished,
its id will be
10.13.1.x
and the head of the 10.13 branch will be advanced to
10.13.1.(x+1)
This is the pattern followed by the JIRA version ids for our other
release branches.
Hope this helps,
-Rick
On 10/2/16, 10:04 AM, Bryan Pendleton wrote:
I'm trying to follow https://wiki.apache.org/db-derby/ReleasePrep
w.r.t. the 10.14 and 10.13 release versions in JIRA.
It's clear that we should have 10.14.0.0, so I added that.
It seems like we don't want to have 10.13.0.0 anymore. Should I
"delete" it?
Or should I "archive" it?
And at what point do I make a 10.13.1.0 (or 10.13.1.1?) version in JIRA.
In https://wiki.apache.org/db-derby/ReleaseCandidates I see:
Add the next release id to JIRA. This is the release id
on the branch. For 10.6 and earlier releases, you will
have bumped this id by hand. For 10.7 releases and later,
the id will have been bumped by the master "release" target.
This allows bugs to be marked as fixed at the head of the
branch. See the following email thread for our latest
thinking on this topic:
http://old.nabble.com/Re%3A-Plans-for-a-10.5.3.1--tt26533770.html#a26577283
Unfortunately, I can't get that email link to work (might be my
ad blocker or privacy settings?).
thanks,
bryan
