Thanks Vinod for bringing up this topic for discussion. I share the same concern here from my previous experience and I doubt some simple rules proposed below could make life easier.
> 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. This is not correct - not reflecting the past and not helpful for the future. There is no benefit to claim 3.0.0-alpha1 is based on 2.7.0 over 2.7.3 (in case 2.8.0 is not there). In the past, for example, when we cut off 2.7, we already have 2.6.0 and 2.6.1 get released, so 2.7.0 take all commits from 2.6.1 (not 2.6.0). In future, assume when we start the release effor of 3.1.0 and we have 3.0.1, 3.0.2, etc., 3.0.x should be more stable than 3.0.0-alpha, so there is unnecessary to do everything from scratch (3.0.0-alpha). So the rule here should be: a new major or minor release should come from a release: 1. tag with stable 2. released latest 3. with maximum version number If condition 2 and 3 get conflicts, we should give priority to 3. For example, when 3.0.0-alpha1 is about to release, assume we have 2.8.0, 2.7.4 and 2.7.4 get released after 2.8.0, then we should claim 3.0.0-alpha is based on 2.8.0 instead of 2.7.4. > 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 don't think setting version tags to be more than 3 is a good practice. The example above means we need to backport this patch to 5 branches which make our committers' life really tough - it requires more effort of committing a patch and also increases the risky of bugs that caused by backport. Given realistic community review bandwidth (please check another thread from Chris D.), I strongly suggest we keep active release train to be less than 3, so we can have 2 stable release or 1 stable release + 1 alpha release in releasing. BTW, I never see we have a clear definition for alpha release. It is previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.) but sometimes means unstable in production quality (2.7.0). I think we should clearly define it with major consensus so user won't misunderstanding the risky here. Also, if we treat our 3.0.0-alpha release work seriously, we should also think about trunk's version number issue (bump up to 4.0.0-alpha?) or there could be no room for 3.0 incompatible feature/bits soon. Just 2 cents. Thanks, Junping 2016-07-27 15:34 GMT+01:00 Karthik Kambatla <ka...@cloudera.com>: > Inline. > > > 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. > > > > Sounds reasonable. > > > > > > 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? > > > > > > 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? > > > > > > Best, > > Andrew > > >
