> > 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. >> > > Once 3.0.0 GA goes out, a user would want to see the diff from the latest > 2.x.0 release (say 2.9.0). > > Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would > apply, and it should show up in the release notes? > > Yea. It means the if you're coming from 2.7, you'd read the 3.0.0-alphas, 3.0.0-betas, and finally the 3.0.0 GA notes.
The website notes will aggregate all the alpha and beta changes leading up to 3.0.0 GA, so is likely where users will turn to first. > >> 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. >> > > > I think it is good practice to set multiple fix versions. However, it > might take the committers a little bit to learn. > > Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the > 3.0.0-alphaX version? > > Yea, I have a script and some JIRA queries that can help with this. I'll also plan to compare with git log contents for extra verification.
