I agree with Konst. The virtues of branching (instead of releasing from trunk) and using the version suffix for the 3.x releases are lost on me. Both introduce opportunities for error, in commits, in consistent JIRA tagging, in packaging...
We can mark stability on the website. If someone builds a cluster without doing this basic research, marking stability in the version number saves them from the least of the problems they'll have. This adds complexity for clarity that's redundant, at best. -C On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <andrew.w...@cloudera.com> wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
