Hi Konst, thanks for commenting, On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <shv.had...@gmail.com> wrote:
> 1. I probably missed something but I didn't get it how "alpha"s made their > way into release numbers again. This was discussed on several occasions and > I thought the common perception was to use just three level numbers for > release versioning and avoid branding them. > It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What > is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to > 3.1.0 would be perfectly in line with our current release practices. > We discussed release numbering a while ago when discussing the release plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a fourth level as you say, but the intent is to only use it (and "-betaX") in the leadup to 3.0.0. The goal here is clarity for end users, since most other enterprise software uses a a.0.0 version to denote the GA of a new major version. Same for a.b.0 for a new minor version, though we haven't talked about that yet. The alphaX and betaX scheme also shares similarity to release versioning of other enterprise software. > > 2. I do not see any confusions with releasing 2.8.0 after 3.0.0. > The release number is not intended to reflect historical release sequence, > but rather the point in the source tree, which it was branched off. So one > can release 2.8, 2.9, etc. after or before 3.0. > As described earlier in this thread, the issue here is setting the fix versions such that the changelog is a useful diff from a previous version, and also clear about what changes are present in each branch. If we do not order a specific 2.x before 3.0, then we don't know what 2.x to diff from. > > 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may > think of another rule that if a release branch is not released in 3 month > it should be abandoned. Which is applicable to branch 2.8.0 and it is too > much work syncing it with branch-2. > > Time-based rules are tough here. I'd prefer we continue to leave this up to release managers. If you think we should recut branch-2.8, recommend pinging Vinod and discussing on a new thread. Best, Andrew
