hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Akira Ajisaka <ajisa...@oss.nttdata.co.jp>
Subject Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Date Wed, 27 Jul 2016 04:35:19 GMT
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 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we need 
to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we 
don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a 
jira. Is it right?

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

(nit) 2.7.3 -> 2.7.4, because branch-2.7.3 has been cut.

Regards,
Akira

On 7/27/16 06:03, Andrew Wang wrote:
> Thanks Vinod for forking the thread. Let me try and summarize what Allen
> and I talked about in the previous thread.
>
> Currently, we've been marking JIRAs with fix versions of both 2.6.x and
> 2.7.x. IIUC, the chronological ordering between these two lines is actually
> not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by
> looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES
> entries. This makes sense from a user POV.
>
> 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.
>
> Having looked at the changelogs of other enterprise software products, this
> is pretty standard.
>
> Perhaps restating the obvious, but:
>
> * For a.b.c releases, the "c"s need to be released in order.
> * For a.b.0 releases, the "b"s need to be released in order.
> * For a.0.0 releases, it comes after a specific x.y.0 release.
>
> 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.
>
> 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.
>
> 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.
>
> Best,
> Andrew
>


---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org


Mime
View raw message