Thanks Vinod for forking the thread. Let me try and summarize what Allen and I talked about in the previous thread.
Currently, we've been marking JIRAs with fix versions of both 2.6.x and 2.7.x. IIUC, the chronological ordering between these two lines is actually not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES entries. This makes sense from a user POV. The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions. Allen's historical perspective is that we've based each minor or major release off of the previous minor release. So, 2.8.0 would be based off of 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also be based off of 2.7.0. This also makes sense from a user POV; someone on a 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes to see what's changed. Having looked at the changelogs of other enterprise software products, this is pretty standard. Perhaps restating the obvious, but: * For a.b.c releases, the "c"s need to be released in order. * For a.b.0 releases, the "b"s need to be released in order. * For a.0.0 releases, it comes after a specific x.y.0 release. Here's an attempt at encoding this policy as a set of rules for setting fix versions (credit to Allen): 1) Set the fix version for all a.b.c versions, where c > 0. 2) For each major release line, set the lowest a.b.0 version. The -alphaX versions we're using leading up to 3.0.0 GA can be treated as a.b.c versions, with alpha1 being the a.b.0 release. As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2, branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3, 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of rule 1, and the last two fix versions come from rule 2. I'm very eager to move this discussion forward, so feel free to reach out on or off list if I can help with anything. Best, Andrew
