Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

yarn-...@hadoop.apache.org; > hdfs-...@hadoop.apache.org; mapreduce-dev@hadoop.apache.org > Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2) > releases [Was Setting JIRA fix versions for 3.0.0 releases] > > I like the 3.0.0-alphaX approach primarily for simpler

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I like the 3.0.0-alphaX approach primarily for simpler understanding of compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing because, it is not immediately clear that 3.0.0 and 3.1.0 could be incompatible in APIs. I am open to something like 2.98.x for alphas and 2.99.x for

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang wrote: > Hi Konst, thanks for commenting, > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko > wrote: > >> 1. I probably missed something but I didn't get it how "alpha"s made >> their way into

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> I'm certainly open to alternate proposals for versioning and fix versions, > but to reiterate, I like this versioning since it imitates other enterprise > software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like > 3.0.0-alpha1 will be immediately familiar to end users.

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas wrote: > 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

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

In the absence of further comments, I've pushed this text to a new "Release Versioning" page on the website. I think svnpubsub automatically builds and pushes for us now, but not 100% sure. Anyway, it seems like we can proceed with the 2.8.0 and 3.0.0-alpha1 version updates. I'm going to be on

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I've written up the proposal from my initial reply in a GDoc. I found one bug in the rules when working through my example again, and also incorporated Akira's correction. Thanks all for the discussion so far! https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Inline. > >> 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

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Hi Junping, thanks for sharing your thoughts, inline, On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 wrote: > 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

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> > 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)

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

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

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

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. >

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks Andrew for sharing your thoughts, It looks better if we can put multiple versions on the fix version, with that we can at least do some queries on JIRA to check the issues like "in branch-2.6.5 but not in branch-2.7.4". I still have a couple of questions: *1) How CHANGES.txt (or release

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> I think I understand a bit better, though now I ask how this date is > different from the release date. OIC. I also assume that the freezing branch cannot include the changes between freezing date and the release date. This is for strict ordering to ensure which is the newer. If we have lots

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I think I understand a bit better, though now I ask how this date is different from the release date. Based on the HowToRelease instructions, we set the release date to when the release vote passes. So, start of release vote vs. end of release vote doesn't seem that different, and these dates are

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> Andrew: I bet many would assume it's the release date, like how Ubuntu releases are numbered. Good point. Maybe I confuse you because of lack of explanation. I assume that "branch-cut off timing" mean the timing of freezing branch like when starting the release vote. It's because that the

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks Vinod and Andrew for the summary. > 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. Assuming

[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Forking the thread to make sure it attracts enough eye-balls. The earlier one was about 3.0.0 specifically and I don’t think enough people were watching that. I’ll try to summarize a bit. # Today’s state of release numbering and ordering: So far, all the releases we have done, we have