You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-dev@hadoop.apache.org by Andrew Wang <an...@cloudera.com> on 2016/07/21 18:34:59 UTC
Setting JIRA fix versions for 3.0.0 releases
Hi all,
Since we're planning to spin releases off of both branch-2 and trunk, the
changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This
is because historically, we've only set 2.x fix versions, and 2.8.0 and
2.9.0 and etc have not been released. So there's a whole bunch of changes
which will show up for the first time in 3.0.0-alpha1.
I think I can write a script to (carefully) add 3.0.0-alpha1 to these
JIRAs, but I figured I'd give a heads up here in case anyone felt
differently. I can also update the HowToCommit page to match.
Thanks,
Andrew
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
Yes, the Java API Compliance Checker allows specifying Annotations to
pare down where incompatible changes happen. It was added some time
ago based on feedback from the Apache HBase project.
The limitations I've found are: 1) at least earlier versions only
supported annotations at the class level (which prevents things like
VisibleForTesting), 2) sometimes it will include more restricted
classes if they are used in less restrictive APIs (e.g. if a IA.Public
class makes use of a IA.Private class in a method signature).
At least when we've used it in HBase, these limitations have been very
easy to spot an explain in a small amount of text. I expect I will be
able to do the same with Hadoop. If we'd like to automate this, the
author has been very responsive to feature requests thus far.
On Mon, Jul 25, 2016 at 3:47 PM, Vinod Kumar Vavilapalli
<vi...@apache.org> wrote:
> Actually, I wouldn’t trust this report as it stands today at all.
>
> I quickly glanced the report, looking for what it highlights as
> incompatible. But the ones that I saw have private / visible for testing
> annotations. Other than acting as useless evidence for those lashing out on
> branch-2, this won’t do much good.
>
> Whenever we start working towards switching to this tool, it should
> incorporate the same exclude-annotations logic that the jdiff code-path does
> today. Do you think that is possible?
>
> Thanks
> +Vinod
>
> On Jul 22, 2016, at 4:53 PM, Vinod Kumar Vavilapalli <vi...@apache.org>
> wrote:
>
> Do you want this check from some particular branch-2 release? It
> matters since the releases along branch-2 have themselves had some
> noise[2].
>
> [1]: https://github.com/lvc/japi-compliance-checker
> <https://github.com/lvc/japi-compliance-checker>
> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
> <http://abi-laboratory.pro/java/tracker/timeline/hadoop/>
>
> --
> busbey
>
>
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
Yes, the Java API Compliance Checker allows specifying Annotations to
pare down where incompatible changes happen. It was added some time
ago based on feedback from the Apache HBase project.
The limitations I've found are: 1) at least earlier versions only
supported annotations at the class level (which prevents things like
VisibleForTesting), 2) sometimes it will include more restricted
classes if they are used in less restrictive APIs (e.g. if a IA.Public
class makes use of a IA.Private class in a method signature).
At least when we've used it in HBase, these limitations have been very
easy to spot an explain in a small amount of text. I expect I will be
able to do the same with Hadoop. If we'd like to automate this, the
author has been very responsive to feature requests thus far.
On Mon, Jul 25, 2016 at 3:47 PM, Vinod Kumar Vavilapalli
<vi...@apache.org> wrote:
> Actually, I wouldn’t trust this report as it stands today at all.
>
> I quickly glanced the report, looking for what it highlights as
> incompatible. But the ones that I saw have private / visible for testing
> annotations. Other than acting as useless evidence for those lashing out on
> branch-2, this won’t do much good.
>
> Whenever we start working towards switching to this tool, it should
> incorporate the same exclude-annotations logic that the jdiff code-path does
> today. Do you think that is possible?
>
> Thanks
> +Vinod
>
> On Jul 22, 2016, at 4:53 PM, Vinod Kumar Vavilapalli <vi...@apache.org>
> wrote:
>
> Do you want this check from some particular branch-2 release? It
> matters since the releases along branch-2 have themselves had some
> noise[2].
>
> [1]: https://github.com/lvc/japi-compliance-checker
> <https://github.com/lvc/japi-compliance-checker>
> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
> <http://abi-laboratory.pro/java/tracker/timeline/hadoop/>
>
> --
> busbey
>
>
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
Yes, the Java API Compliance Checker allows specifying Annotations to
pare down where incompatible changes happen. It was added some time
ago based on feedback from the Apache HBase project.
The limitations I've found are: 1) at least earlier versions only
supported annotations at the class level (which prevents things like
VisibleForTesting), 2) sometimes it will include more restricted
classes if they are used in less restrictive APIs (e.g. if a IA.Public
class makes use of a IA.Private class in a method signature).
At least when we've used it in HBase, these limitations have been very
easy to spot an explain in a small amount of text. I expect I will be
able to do the same with Hadoop. If we'd like to automate this, the
author has been very responsive to feature requests thus far.
On Mon, Jul 25, 2016 at 3:47 PM, Vinod Kumar Vavilapalli
<vi...@apache.org> wrote:
> Actually, I wouldn’t trust this report as it stands today at all.
>
> I quickly glanced the report, looking for what it highlights as
> incompatible. But the ones that I saw have private / visible for testing
> annotations. Other than acting as useless evidence for those lashing out on
> branch-2, this won’t do much good.
>
> Whenever we start working towards switching to this tool, it should
> incorporate the same exclude-annotations logic that the jdiff code-path does
> today. Do you think that is possible?
>
> Thanks
> +Vinod
>
> On Jul 22, 2016, at 4:53 PM, Vinod Kumar Vavilapalli <vi...@apache.org>
> wrote:
>
> Do you want this check from some particular branch-2 release? It
> matters since the releases along branch-2 have themselves had some
> noise[2].
>
> [1]: https://github.com/lvc/japi-compliance-checker
> <https://github.com/lvc/japi-compliance-checker>
> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
> <http://abi-laboratory.pro/java/tracker/timeline/hadoop/>
>
> --
> busbey
>
>
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
Actually, I wouldn’t trust this report as it stands today at all.
I quickly glanced the report, looking for what it highlights as incompatible. But the ones that I saw have private / visible for testing annotations. Other than acting as useless evidence for those lashing out on branch-2, this won’t do much good.
Whenever we start working towards switching to this tool, it should incorporate the same exclude-annotations logic that the jdiff code-path does today. Do you think that is possible?
Thanks
+Vinod
> On Jul 22, 2016, at 4:53 PM, Vinod Kumar Vavilapalli <vi...@apache.org> wrote:
>
>> Do you want this check from some particular branch-2 release? It
>> matters since the releases along branch-2 have themselves had some
>> noise[2].
>>
>> [1]: https://github.com/lvc/japi-compliance-checker <https://github.com/lvc/japi-compliance-checker> <https://github.com/lvc/japi-compliance-checker <https://github.com/lvc/japi-compliance-checker>>
>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/ <http://abi-laboratory.pro/java/tracker/timeline/hadoop/> <http://abi-laboratory.pro/java/tracker/timeline/hadoop/ <http://abi-laboratory.pro/java/tracker/timeline/hadoop/>>
>>
>> --
>> busbey
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
Actually, I wouldn’t trust this report as it stands today at all.
I quickly glanced the report, looking for what it highlights as incompatible. But the ones that I saw have private / visible for testing annotations. Other than acting as useless evidence for those lashing out on branch-2, this won’t do much good.
Whenever we start working towards switching to this tool, it should incorporate the same exclude-annotations logic that the jdiff code-path does today. Do you think that is possible?
Thanks
+Vinod
> On Jul 22, 2016, at 4:53 PM, Vinod Kumar Vavilapalli <vi...@apache.org> wrote:
>
>> Do you want this check from some particular branch-2 release? It
>> matters since the releases along branch-2 have themselves had some
>> noise[2].
>>
>> [1]: https://github.com/lvc/japi-compliance-checker <https://github.com/lvc/japi-compliance-checker> <https://github.com/lvc/japi-compliance-checker <https://github.com/lvc/japi-compliance-checker>>
>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/ <http://abi-laboratory.pro/java/tracker/timeline/hadoop/> <http://abi-laboratory.pro/java/tracker/timeline/hadoop/ <http://abi-laboratory.pro/java/tracker/timeline/hadoop/>>
>>
>> --
>> busbey
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
Actually, I wouldn’t trust this report as it stands today at all.
I quickly glanced the report, looking for what it highlights as incompatible. But the ones that I saw have private / visible for testing annotations. Other than acting as useless evidence for those lashing out on branch-2, this won’t do much good.
Whenever we start working towards switching to this tool, it should incorporate the same exclude-annotations logic that the jdiff code-path does today. Do you think that is possible?
Thanks
+Vinod
> On Jul 22, 2016, at 4:53 PM, Vinod Kumar Vavilapalli <vi...@apache.org> wrote:
>
>> Do you want this check from some particular branch-2 release? It
>> matters since the releases along branch-2 have themselves had some
>> noise[2].
>>
>> [1]: https://github.com/lvc/japi-compliance-checker <https://github.com/lvc/japi-compliance-checker> <https://github.com/lvc/japi-compliance-checker <https://github.com/lvc/japi-compliance-checker>>
>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/ <http://abi-laboratory.pro/java/tracker/timeline/hadoop/> <http://abi-laboratory.pro/java/tracker/timeline/hadoop/ <http://abi-laboratory.pro/java/tracker/timeline/hadoop/>>
>>
>> --
>> busbey
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
I’ve been using jdiff simply because of a lack of alternative.
If you’ve had experience with tool [1], if you think it serves our purpose, and if you can spare some time, that’ll be greatly appreciated. I can also pitch in with whatever help is needed.
I think we should pick one of 2.6.3 or 2.7.2 as baseline.
Thanks
+Vinod
> On Jul 21, 2016, at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> I can come up with this, atleast for Source / Binary API compatibility,
> provided folks don't mind if I use the Java API Compliance Checker[1]
> instead of jdiff.
>
> I'm already familiar with quickly using it, esp with Audience
> Annotations from my work in HBase.
>
> Do you want this check from some particular branch-2 release? It
> matters since the releases along branch-2 have themselves had some
> noise[2].
>
> [1]: https://github.com/lvc/japi-compliance-checker <https://github.com/lvc/japi-compliance-checker>
> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/ <http://abi-laboratory.pro/java/tracker/timeline/hadoop/>
>
> --
> busbey
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
I’ve been using jdiff simply because of a lack of alternative.
If you’ve had experience with tool [1], if you think it serves our purpose, and if you can spare some time, that’ll be greatly appreciated. I can also pitch in with whatever help is needed.
I think we should pick one of 2.6.3 or 2.7.2 as baseline.
Thanks
+Vinod
> On Jul 21, 2016, at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> I can come up with this, atleast for Source / Binary API compatibility,
> provided folks don't mind if I use the Java API Compliance Checker[1]
> instead of jdiff.
>
> I'm already familiar with quickly using it, esp with Audience
> Annotations from my work in HBase.
>
> Do you want this check from some particular branch-2 release? It
> matters since the releases along branch-2 have themselves had some
> noise[2].
>
> [1]: https://github.com/lvc/japi-compliance-checker <https://github.com/lvc/japi-compliance-checker>
> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/ <http://abi-laboratory.pro/java/tracker/timeline/hadoop/>
>
> --
> busbey
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
I’ve been using jdiff simply because of a lack of alternative.
If you’ve had experience with tool [1], if you think it serves our purpose, and if you can spare some time, that’ll be greatly appreciated. I can also pitch in with whatever help is needed.
I think we should pick one of 2.6.3 or 2.7.2 as baseline.
Thanks
+Vinod
> On Jul 21, 2016, at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> I can come up with this, atleast for Source / Binary API compatibility,
> provided folks don't mind if I use the Java API Compliance Checker[1]
> instead of jdiff.
>
> I'm already familiar with quickly using it, esp with Audience
> Annotations from my work in HBase.
>
> Do you want this check from some particular branch-2 release? It
> matters since the releases along branch-2 have themselves had some
> noise[2].
>
> [1]: https://github.com/lvc/japi-compliance-checker <https://github.com/lvc/japi-compliance-checker>
> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/ <http://abi-laboratory.pro/java/tracker/timeline/hadoop/>
>
> --
> busbey
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
I've taken a look at the Common and HDFS compat issues.
* A bunch of them are from the known removals of the deprecated Metrics 1
and RCC. JACC understands and can filter @Deprecated annotations, but
HADOOP-7266 isn't in 2.7.2, and apparently JACC doesn't look at the class
annotation when telling you some methods were removed. Filed:
https://github.com/lvc/japi-compliance-checker/issues/33
* The tool doesn't detect when you add a type parameter to a
super-interface, which I think is compatible. Filed a JACC issue:
https://github.com/lvc/japi-compliance-checker/issues/32
* It did find HDFS-10793, a legit audit logger issue which is an issue for
2.8.0 also. Manoj is closing on this, we're just waiting on a precommit run
before committing.
This list also includes LimitedPrivate classes, so things like DU and
KerberosName show up here too. I think it's good to check LimitedPrivate
too since practically speaking many of these should be Public, but I can
generate a Public only report if desired.
If someone wants to take a look at the YARN changes, that'd be swell. Since
things overall look good though, I'm going get back to rebranching for
3.0.0-alpha1 and the corresponding fix version updates.
On Thu, Aug 25, 2016 at 11:44 AM, Andrew Wang <an...@cloudera.com>
wrote:
> Sean gave me some pointers on using Java ACC, I've made a report using the
> script I've been working on at YETUS-445:
>
> http://home.apache.org/~wang/h3/report.html
>
> Invocation was something like this:
>
> -> % ~/dev/yetus/check-java-compatibility/checkjavacompatibility.py
> --annotation org.apache.hadoop.classification.InterfaceAudience.Public
> --annotation org.apache.hadoop.classification.InterfaceAudience.LimitedPrivate
> --include "hadoop.*" branch-2.7.2 trunk
>
> I think this report is easier to consume than JDiff. If we like it, I can
> generate one for 2.7.2 -> 2.8.0, and it should be easy to automate via
> Jenkins as well.
>
>
> On Tue, Jul 26, 2016 at 11:28 AM, Wangda Tan <wh...@gmail.com> wrote:
>
>> Hi all,
>>
>> I'm trying to generate JDiff for sub projects of Hadoop, some updates:
>> *- Common*: JDiff cannot be generated , filed https://issues.apache.or
>> g/jira/browse/HADOOP-13428 and debugging that.
>> - *HDFS*: It pointed to a older version (2.6.0), we need to upgrade it
>> to the latest stable release (probably 2.7.3, it is mostly done). filed
>> https://issues.apache.org/jira/browse/HDFS-10692 and will work on that
>> - *YARN*: JDiff can be generated, we need to do analysis for it.
>> - *MR*: JDiff cannot be generated, https://issues.apac
>> he.org/jira/browse/MAPREDUCE-6310 is tracking it.
>>
>> I'm currently actively working on these items, any helps will be
>> appreciated.
>>
>> Thanks,
>> Wangda
>>
>> On Tue, Jul 26, 2016 at 11:16 AM, Vinod Kumar Vavilapalli <
>> vinodkv@apache.org> wrote:
>>
>>> +1
>>>
>>> Thanks
>>> +Vinod
>>>
>>> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>>>
>>> lets try to use both jdiff and the new tool and compare results because
>>> this is the first time with the new tool.
>>>
>>> Appreciate your time to help us about this effort!
>>>
>>>
>>>
>>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
I've taken a look at the Common and HDFS compat issues.
* A bunch of them are from the known removals of the deprecated Metrics 1
and RCC. JACC understands and can filter @Deprecated annotations, but
HADOOP-7266 isn't in 2.7.2, and apparently JACC doesn't look at the class
annotation when telling you some methods were removed. Filed:
https://github.com/lvc/japi-compliance-checker/issues/33
* The tool doesn't detect when you add a type parameter to a
super-interface, which I think is compatible. Filed a JACC issue:
https://github.com/lvc/japi-compliance-checker/issues/32
* It did find HDFS-10793, a legit audit logger issue which is an issue for
2.8.0 also. Manoj is closing on this, we're just waiting on a precommit run
before committing.
This list also includes LimitedPrivate classes, so things like DU and
KerberosName show up here too. I think it's good to check LimitedPrivate
too since practically speaking many of these should be Public, but I can
generate a Public only report if desired.
If someone wants to take a look at the YARN changes, that'd be swell. Since
things overall look good though, I'm going get back to rebranching for
3.0.0-alpha1 and the corresponding fix version updates.
On Thu, Aug 25, 2016 at 11:44 AM, Andrew Wang <an...@cloudera.com>
wrote:
> Sean gave me some pointers on using Java ACC, I've made a report using the
> script I've been working on at YETUS-445:
>
> http://home.apache.org/~wang/h3/report.html
>
> Invocation was something like this:
>
> -> % ~/dev/yetus/check-java-compatibility/checkjavacompatibility.py
> --annotation org.apache.hadoop.classification.InterfaceAudience.Public
> --annotation org.apache.hadoop.classification.InterfaceAudience.LimitedPrivate
> --include "hadoop.*" branch-2.7.2 trunk
>
> I think this report is easier to consume than JDiff. If we like it, I can
> generate one for 2.7.2 -> 2.8.0, and it should be easy to automate via
> Jenkins as well.
>
>
> On Tue, Jul 26, 2016 at 11:28 AM, Wangda Tan <wh...@gmail.com> wrote:
>
>> Hi all,
>>
>> I'm trying to generate JDiff for sub projects of Hadoop, some updates:
>> *- Common*: JDiff cannot be generated , filed https://issues.apache.or
>> g/jira/browse/HADOOP-13428 and debugging that.
>> - *HDFS*: It pointed to a older version (2.6.0), we need to upgrade it
>> to the latest stable release (probably 2.7.3, it is mostly done). filed
>> https://issues.apache.org/jira/browse/HDFS-10692 and will work on that
>> - *YARN*: JDiff can be generated, we need to do analysis for it.
>> - *MR*: JDiff cannot be generated, https://issues.apac
>> he.org/jira/browse/MAPREDUCE-6310 is tracking it.
>>
>> I'm currently actively working on these items, any helps will be
>> appreciated.
>>
>> Thanks,
>> Wangda
>>
>> On Tue, Jul 26, 2016 at 11:16 AM, Vinod Kumar Vavilapalli <
>> vinodkv@apache.org> wrote:
>>
>>> +1
>>>
>>> Thanks
>>> +Vinod
>>>
>>> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>>>
>>> lets try to use both jdiff and the new tool and compare results because
>>> this is the first time with the new tool.
>>>
>>> Appreciate your time to help us about this effort!
>>>
>>>
>>>
>>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
I've taken a look at the Common and HDFS compat issues.
* A bunch of them are from the known removals of the deprecated Metrics 1
and RCC. JACC understands and can filter @Deprecated annotations, but
HADOOP-7266 isn't in 2.7.2, and apparently JACC doesn't look at the class
annotation when telling you some methods were removed. Filed:
https://github.com/lvc/japi-compliance-checker/issues/33
* The tool doesn't detect when you add a type parameter to a
super-interface, which I think is compatible. Filed a JACC issue:
https://github.com/lvc/japi-compliance-checker/issues/32
* It did find HDFS-10793, a legit audit logger issue which is an issue for
2.8.0 also. Manoj is closing on this, we're just waiting on a precommit run
before committing.
This list also includes LimitedPrivate classes, so things like DU and
KerberosName show up here too. I think it's good to check LimitedPrivate
too since practically speaking many of these should be Public, but I can
generate a Public only report if desired.
If someone wants to take a look at the YARN changes, that'd be swell. Since
things overall look good though, I'm going get back to rebranching for
3.0.0-alpha1 and the corresponding fix version updates.
On Thu, Aug 25, 2016 at 11:44 AM, Andrew Wang <an...@cloudera.com>
wrote:
> Sean gave me some pointers on using Java ACC, I've made a report using the
> script I've been working on at YETUS-445:
>
> http://home.apache.org/~wang/h3/report.html
>
> Invocation was something like this:
>
> -> % ~/dev/yetus/check-java-compatibility/checkjavacompatibility.py
> --annotation org.apache.hadoop.classification.InterfaceAudience.Public
> --annotation org.apache.hadoop.classification.InterfaceAudience.LimitedPrivate
> --include "hadoop.*" branch-2.7.2 trunk
>
> I think this report is easier to consume than JDiff. If we like it, I can
> generate one for 2.7.2 -> 2.8.0, and it should be easy to automate via
> Jenkins as well.
>
>
> On Tue, Jul 26, 2016 at 11:28 AM, Wangda Tan <wh...@gmail.com> wrote:
>
>> Hi all,
>>
>> I'm trying to generate JDiff for sub projects of Hadoop, some updates:
>> *- Common*: JDiff cannot be generated , filed https://issues.apache.or
>> g/jira/browse/HADOOP-13428 and debugging that.
>> - *HDFS*: It pointed to a older version (2.6.0), we need to upgrade it
>> to the latest stable release (probably 2.7.3, it is mostly done). filed
>> https://issues.apache.org/jira/browse/HDFS-10692 and will work on that
>> - *YARN*: JDiff can be generated, we need to do analysis for it.
>> - *MR*: JDiff cannot be generated, https://issues.apac
>> he.org/jira/browse/MAPREDUCE-6310 is tracking it.
>>
>> I'm currently actively working on these items, any helps will be
>> appreciated.
>>
>> Thanks,
>> Wangda
>>
>> On Tue, Jul 26, 2016 at 11:16 AM, Vinod Kumar Vavilapalli <
>> vinodkv@apache.org> wrote:
>>
>>> +1
>>>
>>> Thanks
>>> +Vinod
>>>
>>> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>>>
>>> lets try to use both jdiff and the new tool and compare results because
>>> this is the first time with the new tool.
>>>
>>> Appreciate your time to help us about this effort!
>>>
>>>
>>>
>>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Sean gave me some pointers on using Java ACC, I've made a report using the
script I've been working on at YETUS-445:
http://home.apache.org/~wang/h3/report.html
Invocation was something like this:
-> % ~/dev/yetus/check-java-compatibility/checkjavacompatibility.py
--annotation org.apache.hadoop.classification.InterfaceAudience.Public
--annotation
org.apache.hadoop.classification.InterfaceAudience.LimitedPrivate --include
"hadoop.*" branch-2.7.2 trunk
I think this report is easier to consume than JDiff. If we like it, I can
generate one for 2.7.2 -> 2.8.0, and it should be easy to automate via
Jenkins as well.
On Tue, Jul 26, 2016 at 11:28 AM, Wangda Tan <wh...@gmail.com> wrote:
> Hi all,
>
> I'm trying to generate JDiff for sub projects of Hadoop, some updates:
> *- Common*: JDiff cannot be generated , filed https://issues.apache.
> org/jira/browse/HADOOP-13428 and debugging that.
> - *HDFS*: It pointed to a older version (2.6.0), we need to upgrade it to
> the latest stable release (probably 2.7.3, it is mostly done). filed
> https://issues.apache.org/jira/browse/HDFS-10692 and will work on that
> - *YARN*: JDiff can be generated, we need to do analysis for it.
> - *MR*: JDiff cannot be generated, https://issues.apache.org/jira/browse/
> MAPREDUCE-6310 is tracking it.
>
> I'm currently actively working on these items, any helps will be
> appreciated.
>
> Thanks,
> Wangda
>
> On Tue, Jul 26, 2016 at 11:16 AM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org> wrote:
>
>> +1
>>
>> Thanks
>> +Vinod
>>
>> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>>
>> lets try to use both jdiff and the new tool and compare results because
>> this is the first time with the new tool.
>>
>> Appreciate your time to help us about this effort!
>>
>>
>>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Sean gave me some pointers on using Java ACC, I've made a report using the
script I've been working on at YETUS-445:
http://home.apache.org/~wang/h3/report.html
Invocation was something like this:
-> % ~/dev/yetus/check-java-compatibility/checkjavacompatibility.py
--annotation org.apache.hadoop.classification.InterfaceAudience.Public
--annotation
org.apache.hadoop.classification.InterfaceAudience.LimitedPrivate --include
"hadoop.*" branch-2.7.2 trunk
I think this report is easier to consume than JDiff. If we like it, I can
generate one for 2.7.2 -> 2.8.0, and it should be easy to automate via
Jenkins as well.
On Tue, Jul 26, 2016 at 11:28 AM, Wangda Tan <wh...@gmail.com> wrote:
> Hi all,
>
> I'm trying to generate JDiff for sub projects of Hadoop, some updates:
> *- Common*: JDiff cannot be generated , filed https://issues.apache.
> org/jira/browse/HADOOP-13428 and debugging that.
> - *HDFS*: It pointed to a older version (2.6.0), we need to upgrade it to
> the latest stable release (probably 2.7.3, it is mostly done). filed
> https://issues.apache.org/jira/browse/HDFS-10692 and will work on that
> - *YARN*: JDiff can be generated, we need to do analysis for it.
> - *MR*: JDiff cannot be generated, https://issues.apache.org/jira/browse/
> MAPREDUCE-6310 is tracking it.
>
> I'm currently actively working on these items, any helps will be
> appreciated.
>
> Thanks,
> Wangda
>
> On Tue, Jul 26, 2016 at 11:16 AM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org> wrote:
>
>> +1
>>
>> Thanks
>> +Vinod
>>
>> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>>
>> lets try to use both jdiff and the new tool and compare results because
>> this is the first time with the new tool.
>>
>> Appreciate your time to help us about this effort!
>>
>>
>>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Sean gave me some pointers on using Java ACC, I've made a report using the
script I've been working on at YETUS-445:
http://home.apache.org/~wang/h3/report.html
Invocation was something like this:
-> % ~/dev/yetus/check-java-compatibility/checkjavacompatibility.py
--annotation org.apache.hadoop.classification.InterfaceAudience.Public
--annotation
org.apache.hadoop.classification.InterfaceAudience.LimitedPrivate --include
"hadoop.*" branch-2.7.2 trunk
I think this report is easier to consume than JDiff. If we like it, I can
generate one for 2.7.2 -> 2.8.0, and it should be easy to automate via
Jenkins as well.
On Tue, Jul 26, 2016 at 11:28 AM, Wangda Tan <wh...@gmail.com> wrote:
> Hi all,
>
> I'm trying to generate JDiff for sub projects of Hadoop, some updates:
> *- Common*: JDiff cannot be generated , filed https://issues.apache.
> org/jira/browse/HADOOP-13428 and debugging that.
> - *HDFS*: It pointed to a older version (2.6.0), we need to upgrade it to
> the latest stable release (probably 2.7.3, it is mostly done). filed
> https://issues.apache.org/jira/browse/HDFS-10692 and will work on that
> - *YARN*: JDiff can be generated, we need to do analysis for it.
> - *MR*: JDiff cannot be generated, https://issues.apache.org/jira/browse/
> MAPREDUCE-6310 is tracking it.
>
> I'm currently actively working on these items, any helps will be
> appreciated.
>
> Thanks,
> Wangda
>
> On Tue, Jul 26, 2016 at 11:16 AM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org> wrote:
>
>> +1
>>
>> Thanks
>> +Vinod
>>
>> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>>
>> lets try to use both jdiff and the new tool and compare results because
>> this is the first time with the new tool.
>>
>> Appreciate your time to help us about this effort!
>>
>>
>>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
Hi all,
I'm trying to generate JDiff for sub projects of Hadoop, some updates:
*- Common*: JDiff cannot be generated , filed
https://issues.apache.org/jira/browse/HADOOP-13428 and debugging that.
- *HDFS*: It pointed to a older version (2.6.0), we need to upgrade it to
the latest stable release (probably 2.7.3, it is mostly done). filed
https://issues.apache.org/jira/browse/HDFS-10692 and will work on that
- *YARN*: JDiff can be generated, we need to do analysis for it.
- *MR*: JDiff cannot be generated,
https://issues.apache.org/jira/browse/MAPREDUCE-6310 is tracking it.
I'm currently actively working on these items, any helps will be
appreciated.
Thanks,
Wangda
On Tue, Jul 26, 2016 at 11:16 AM, Vinod Kumar Vavilapalli <
vinodkv@apache.org> wrote:
> +1
>
> Thanks
> +Vinod
>
> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>
> lets try to use both jdiff and the new tool and compare results because
> this is the first time with the new tool.
>
> Appreciate your time to help us about this effort!
>
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
Hi all,
I'm trying to generate JDiff for sub projects of Hadoop, some updates:
*- Common*: JDiff cannot be generated , filed
https://issues.apache.org/jira/browse/HADOOP-13428 and debugging that.
- *HDFS*: It pointed to a older version (2.6.0), we need to upgrade it to
the latest stable release (probably 2.7.3, it is mostly done). filed
https://issues.apache.org/jira/browse/HDFS-10692 and will work on that
- *YARN*: JDiff can be generated, we need to do analysis for it.
- *MR*: JDiff cannot be generated,
https://issues.apache.org/jira/browse/MAPREDUCE-6310 is tracking it.
I'm currently actively working on these items, any helps will be
appreciated.
Thanks,
Wangda
On Tue, Jul 26, 2016 at 11:16 AM, Vinod Kumar Vavilapalli <
vinodkv@apache.org> wrote:
> +1
>
> Thanks
> +Vinod
>
> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>
> lets try to use both jdiff and the new tool and compare results because
> this is the first time with the new tool.
>
> Appreciate your time to help us about this effort!
>
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
Hi all,
I'm trying to generate JDiff for sub projects of Hadoop, some updates:
*- Common*: JDiff cannot be generated , filed
https://issues.apache.org/jira/browse/HADOOP-13428 and debugging that.
- *HDFS*: It pointed to a older version (2.6.0), we need to upgrade it to
the latest stable release (probably 2.7.3, it is mostly done). filed
https://issues.apache.org/jira/browse/HDFS-10692 and will work on that
- *YARN*: JDiff can be generated, we need to do analysis for it.
- *MR*: JDiff cannot be generated,
https://issues.apache.org/jira/browse/MAPREDUCE-6310 is tracking it.
I'm currently actively working on these items, any helps will be
appreciated.
Thanks,
Wangda
On Tue, Jul 26, 2016 at 11:16 AM, Vinod Kumar Vavilapalli <
vinodkv@apache.org> wrote:
> +1
>
> Thanks
> +Vinod
>
> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>
> lets try to use both jdiff and the new tool and compare results because
> this is the first time with the new tool.
>
> Appreciate your time to help us about this effort!
>
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
+1
Thanks
+Vinod
> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>
> lets try to use both jdiff and the new tool and compare results because this is the first time with the new tool.
>
> Appreciate your time to help us about this effort!
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
+1
Thanks
+Vinod
> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>
> lets try to use both jdiff and the new tool and compare results because this is the first time with the new tool.
>
> Appreciate your time to help us about this effort!
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
+1
Thanks
+Vinod
> On Jul 26, 2016, at 7:39 AM, Wangda Tan <wh...@gmail.com> wrote:
>
> lets try to use both jdiff and the new tool and compare results because this is the first time with the new tool.
>
> Appreciate your time to help us about this effort!
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
Hi Sean,
Sorry I didn't make it clear, lets try to use both jdiff and the new tool and compare results because this is the first time with the new tool.
Appreciate your time to help us about this effort!
Thanks,
Wangda
Sent from my iPhone
> On Jul 26, 2016, at 6:01 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> Just so I don't waste time chasing my tail, should I interpret this
> email and the associated JIRA as the PMC preferring I not spend
> volunteer time providing a compatibility breakdown as previously
> discussed?
>
>> On Mon, Jul 25, 2016 at 7:54 PM, Wangda Tan <wh...@gmail.com> wrote:
>> I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to
>> track running JDIFF on trunk and analyze results for Hadoop-common. I will
>> work on that and keep the JIRA and this thread updated. We need to do the
>> same work for YARN/MR/HDFS.
>>
>>> On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan <wh...@gmail.com> wrote:
>>>
>>> I agree with what Vinod mentioned: we need to revisit all incompatible
>>> changes and revert unnecessary ones. Even if we don't have any compatibility
>>> guarantees between 2.x and 3.x. But make user to be less frustrated while
>>> trying 3.x is always a better option to me.
>>>
>>> To achieve this we need to run jdiff for trunk and look at results. I
>>> would suggest to do this before 3.0.0-alpha1 release.
>>>
>>> In addition, for people who will try this 3-alpha1 release artifacts, a
>>> guide about migration from 2.x to 3.x will be very helpful, and it can also
>>> help for people to better understand what have changed (Just like
>>> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html)
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Wangda
>>>
>>>
>>>> On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>>>>
>>>> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
>>>> <vi...@apache.org> wrote:
>>>>>> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
>>>>>> impossible for downstreams to test incompat changes and new features without
>>>>>> a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is
>>>>>> ready for an RC besides possibly this fix version issue.
>>>>>
>>>>> Not arguing against the need for an alpha release, the question is if
>>>>> it can wait till after 2.8 gets done.
>>>>>
>>>>> Orthogonally, do we have a report of the incompatible changes? Like the
>>>>> one I generated for some of the branch-2 releases using late jdiff work from
>>>>> Li Lu etc. We should do this and fix any inadvertant incompatibilities.
>>>>> Without seeing this list of incompatibilities, why even make an alpha
>>>>> release and force downstream components to discover issues what can be
>>>>> identified through running reports.
>>>>
>>>> I can come up with this, atleast for Source / Binary API compatibility,
>>>> provided folks don't mind if I use the Java API Compliance Checker[1]
>>>> instead of jdiff.
>>>>
>>>> I'm already familiar with quickly using it, esp with Audience
>>>> Annotations from my work in HBase.
>>>>
>>>> Do you want this check from some particular branch-2 release? It
>>>> matters since the releases along branch-2 have themselves had some
>>>> noise[2].
>>>>
>>>> [1]: https://github.com/lvc/japi-compliance-checker
>>>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>>>>
>>>> --
>>>> busbey
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>>>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
>
> --
> busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
Hi Sean,
Sorry I didn't make it clear, lets try to use both jdiff and the new tool and compare results because this is the first time with the new tool.
Appreciate your time to help us about this effort!
Thanks,
Wangda
Sent from my iPhone
> On Jul 26, 2016, at 6:01 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> Just so I don't waste time chasing my tail, should I interpret this
> email and the associated JIRA as the PMC preferring I not spend
> volunteer time providing a compatibility breakdown as previously
> discussed?
>
>> On Mon, Jul 25, 2016 at 7:54 PM, Wangda Tan <wh...@gmail.com> wrote:
>> I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to
>> track running JDIFF on trunk and analyze results for Hadoop-common. I will
>> work on that and keep the JIRA and this thread updated. We need to do the
>> same work for YARN/MR/HDFS.
>>
>>> On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan <wh...@gmail.com> wrote:
>>>
>>> I agree with what Vinod mentioned: we need to revisit all incompatible
>>> changes and revert unnecessary ones. Even if we don't have any compatibility
>>> guarantees between 2.x and 3.x. But make user to be less frustrated while
>>> trying 3.x is always a better option to me.
>>>
>>> To achieve this we need to run jdiff for trunk and look at results. I
>>> would suggest to do this before 3.0.0-alpha1 release.
>>>
>>> In addition, for people who will try this 3-alpha1 release artifacts, a
>>> guide about migration from 2.x to 3.x will be very helpful, and it can also
>>> help for people to better understand what have changed (Just like
>>> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html)
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Wangda
>>>
>>>
>>>> On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>>>>
>>>> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
>>>> <vi...@apache.org> wrote:
>>>>>> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
>>>>>> impossible for downstreams to test incompat changes and new features without
>>>>>> a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is
>>>>>> ready for an RC besides possibly this fix version issue.
>>>>>
>>>>> Not arguing against the need for an alpha release, the question is if
>>>>> it can wait till after 2.8 gets done.
>>>>>
>>>>> Orthogonally, do we have a report of the incompatible changes? Like the
>>>>> one I generated for some of the branch-2 releases using late jdiff work from
>>>>> Li Lu etc. We should do this and fix any inadvertant incompatibilities.
>>>>> Without seeing this list of incompatibilities, why even make an alpha
>>>>> release and force downstream components to discover issues what can be
>>>>> identified through running reports.
>>>>
>>>> I can come up with this, atleast for Source / Binary API compatibility,
>>>> provided folks don't mind if I use the Java API Compliance Checker[1]
>>>> instead of jdiff.
>>>>
>>>> I'm already familiar with quickly using it, esp with Audience
>>>> Annotations from my work in HBase.
>>>>
>>>> Do you want this check from some particular branch-2 release? It
>>>> matters since the releases along branch-2 have themselves had some
>>>> noise[2].
>>>>
>>>> [1]: https://github.com/lvc/japi-compliance-checker
>>>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>>>>
>>>> --
>>>> busbey
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>>>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
>
> --
> busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
Hi Sean,
Sorry I didn't make it clear, lets try to use both jdiff and the new tool and compare results because this is the first time with the new tool.
Appreciate your time to help us about this effort!
Thanks,
Wangda
Sent from my iPhone
> On Jul 26, 2016, at 6:01 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> Just so I don't waste time chasing my tail, should I interpret this
> email and the associated JIRA as the PMC preferring I not spend
> volunteer time providing a compatibility breakdown as previously
> discussed?
>
>> On Mon, Jul 25, 2016 at 7:54 PM, Wangda Tan <wh...@gmail.com> wrote:
>> I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to
>> track running JDIFF on trunk and analyze results for Hadoop-common. I will
>> work on that and keep the JIRA and this thread updated. We need to do the
>> same work for YARN/MR/HDFS.
>>
>>> On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan <wh...@gmail.com> wrote:
>>>
>>> I agree with what Vinod mentioned: we need to revisit all incompatible
>>> changes and revert unnecessary ones. Even if we don't have any compatibility
>>> guarantees between 2.x and 3.x. But make user to be less frustrated while
>>> trying 3.x is always a better option to me.
>>>
>>> To achieve this we need to run jdiff for trunk and look at results. I
>>> would suggest to do this before 3.0.0-alpha1 release.
>>>
>>> In addition, for people who will try this 3-alpha1 release artifacts, a
>>> guide about migration from 2.x to 3.x will be very helpful, and it can also
>>> help for people to better understand what have changed (Just like
>>> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html)
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Wangda
>>>
>>>
>>>> On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>>>>
>>>> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
>>>> <vi...@apache.org> wrote:
>>>>>> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
>>>>>> impossible for downstreams to test incompat changes and new features without
>>>>>> a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is
>>>>>> ready for an RC besides possibly this fix version issue.
>>>>>
>>>>> Not arguing against the need for an alpha release, the question is if
>>>>> it can wait till after 2.8 gets done.
>>>>>
>>>>> Orthogonally, do we have a report of the incompatible changes? Like the
>>>>> one I generated for some of the branch-2 releases using late jdiff work from
>>>>> Li Lu etc. We should do this and fix any inadvertant incompatibilities.
>>>>> Without seeing this list of incompatibilities, why even make an alpha
>>>>> release and force downstream components to discover issues what can be
>>>>> identified through running reports.
>>>>
>>>> I can come up with this, atleast for Source / Binary API compatibility,
>>>> provided folks don't mind if I use the Java API Compliance Checker[1]
>>>> instead of jdiff.
>>>>
>>>> I'm already familiar with quickly using it, esp with Audience
>>>> Annotations from my work in HBase.
>>>>
>>>> Do you want this check from some particular branch-2 release? It
>>>> matters since the releases along branch-2 have themselves had some
>>>> noise[2].
>>>>
>>>> [1]: https://github.com/lvc/japi-compliance-checker
>>>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>>>>
>>>> --
>>>> busbey
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>>>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
>
> --
> busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
Just so I don't waste time chasing my tail, should I interpret this
email and the associated JIRA as the PMC preferring I not spend
volunteer time providing a compatibility breakdown as previously
discussed?
On Mon, Jul 25, 2016 at 7:54 PM, Wangda Tan <wh...@gmail.com> wrote:
> I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to
> track running JDIFF on trunk and analyze results for Hadoop-common. I will
> work on that and keep the JIRA and this thread updated. We need to do the
> same work for YARN/MR/HDFS.
>
> On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan <wh...@gmail.com> wrote:
>>
>> I agree with what Vinod mentioned: we need to revisit all incompatible
>> changes and revert unnecessary ones. Even if we don't have any compatibility
>> guarantees between 2.x and 3.x. But make user to be less frustrated while
>> trying 3.x is always a better option to me.
>>
>> To achieve this we need to run jdiff for trunk and look at results. I
>> would suggest to do this before 3.0.0-alpha1 release.
>>
>> In addition, for people who will try this 3-alpha1 release artifacts, a
>> guide about migration from 2.x to 3.x will be very helpful, and it can also
>> help for people to better understand what have changed (Just like
>> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html)
>>
>> Thoughts?
>>
>> Thanks,
>> Wangda
>>
>>
>> On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>>>
>>> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
>>> <vi...@apache.org> wrote:
>>> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
>>> >> impossible for downstreams to test incompat changes and new features without
>>> >> a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is
>>> >> ready for an RC besides possibly this fix version issue.
>>> >
>>> > Not arguing against the need for an alpha release, the question is if
>>> > it can wait till after 2.8 gets done.
>>> >
>>> > Orthogonally, do we have a report of the incompatible changes? Like the
>>> > one I generated for some of the branch-2 releases using late jdiff work from
>>> > Li Lu etc. We should do this and fix any inadvertant incompatibilities.
>>> > Without seeing this list of incompatibilities, why even make an alpha
>>> > release and force downstream components to discover issues what can be
>>> > identified through running reports.
>>> >
>>>
>>> I can come up with this, atleast for Source / Binary API compatibility,
>>> provided folks don't mind if I use the Java API Compliance Checker[1]
>>> instead of jdiff.
>>>
>>> I'm already familiar with quickly using it, esp with Audience
>>> Annotations from my work in HBase.
>>>
>>> Do you want this check from some particular branch-2 release? It
>>> matters since the releases along branch-2 have themselves had some
>>> noise[2].
>>>
>>> [1]: https://github.com/lvc/japi-compliance-checker
>>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>>>
>>> --
>>> busbey
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>>>
>>
>
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
Just so I don't waste time chasing my tail, should I interpret this
email and the associated JIRA as the PMC preferring I not spend
volunteer time providing a compatibility breakdown as previously
discussed?
On Mon, Jul 25, 2016 at 7:54 PM, Wangda Tan <wh...@gmail.com> wrote:
> I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to
> track running JDIFF on trunk and analyze results for Hadoop-common. I will
> work on that and keep the JIRA and this thread updated. We need to do the
> same work for YARN/MR/HDFS.
>
> On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan <wh...@gmail.com> wrote:
>>
>> I agree with what Vinod mentioned: we need to revisit all incompatible
>> changes and revert unnecessary ones. Even if we don't have any compatibility
>> guarantees between 2.x and 3.x. But make user to be less frustrated while
>> trying 3.x is always a better option to me.
>>
>> To achieve this we need to run jdiff for trunk and look at results. I
>> would suggest to do this before 3.0.0-alpha1 release.
>>
>> In addition, for people who will try this 3-alpha1 release artifacts, a
>> guide about migration from 2.x to 3.x will be very helpful, and it can also
>> help for people to better understand what have changed (Just like
>> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html)
>>
>> Thoughts?
>>
>> Thanks,
>> Wangda
>>
>>
>> On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>>>
>>> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
>>> <vi...@apache.org> wrote:
>>> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
>>> >> impossible for downstreams to test incompat changes and new features without
>>> >> a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is
>>> >> ready for an RC besides possibly this fix version issue.
>>> >
>>> > Not arguing against the need for an alpha release, the question is if
>>> > it can wait till after 2.8 gets done.
>>> >
>>> > Orthogonally, do we have a report of the incompatible changes? Like the
>>> > one I generated for some of the branch-2 releases using late jdiff work from
>>> > Li Lu etc. We should do this and fix any inadvertant incompatibilities.
>>> > Without seeing this list of incompatibilities, why even make an alpha
>>> > release and force downstream components to discover issues what can be
>>> > identified through running reports.
>>> >
>>>
>>> I can come up with this, atleast for Source / Binary API compatibility,
>>> provided folks don't mind if I use the Java API Compliance Checker[1]
>>> instead of jdiff.
>>>
>>> I'm already familiar with quickly using it, esp with Audience
>>> Annotations from my work in HBase.
>>>
>>> Do you want this check from some particular branch-2 release? It
>>> matters since the releases along branch-2 have themselves had some
>>> noise[2].
>>>
>>> [1]: https://github.com/lvc/japi-compliance-checker
>>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>>>
>>> --
>>> busbey
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>>>
>>
>
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
Just so I don't waste time chasing my tail, should I interpret this
email and the associated JIRA as the PMC preferring I not spend
volunteer time providing a compatibility breakdown as previously
discussed?
On Mon, Jul 25, 2016 at 7:54 PM, Wangda Tan <wh...@gmail.com> wrote:
> I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to
> track running JDIFF on trunk and analyze results for Hadoop-common. I will
> work on that and keep the JIRA and this thread updated. We need to do the
> same work for YARN/MR/HDFS.
>
> On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan <wh...@gmail.com> wrote:
>>
>> I agree with what Vinod mentioned: we need to revisit all incompatible
>> changes and revert unnecessary ones. Even if we don't have any compatibility
>> guarantees between 2.x and 3.x. But make user to be less frustrated while
>> trying 3.x is always a better option to me.
>>
>> To achieve this we need to run jdiff for trunk and look at results. I
>> would suggest to do this before 3.0.0-alpha1 release.
>>
>> In addition, for people who will try this 3-alpha1 release artifacts, a
>> guide about migration from 2.x to 3.x will be very helpful, and it can also
>> help for people to better understand what have changed (Just like
>> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html)
>>
>> Thoughts?
>>
>> Thanks,
>> Wangda
>>
>>
>> On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>>>
>>> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
>>> <vi...@apache.org> wrote:
>>> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
>>> >> impossible for downstreams to test incompat changes and new features without
>>> >> a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is
>>> >> ready for an RC besides possibly this fix version issue.
>>> >
>>> > Not arguing against the need for an alpha release, the question is if
>>> > it can wait till after 2.8 gets done.
>>> >
>>> > Orthogonally, do we have a report of the incompatible changes? Like the
>>> > one I generated for some of the branch-2 releases using late jdiff work from
>>> > Li Lu etc. We should do this and fix any inadvertant incompatibilities.
>>> > Without seeing this list of incompatibilities, why even make an alpha
>>> > release and force downstream components to discover issues what can be
>>> > identified through running reports.
>>> >
>>>
>>> I can come up with this, atleast for Source / Binary API compatibility,
>>> provided folks don't mind if I use the Java API Compliance Checker[1]
>>> instead of jdiff.
>>>
>>> I'm already familiar with quickly using it, esp with Audience
>>> Annotations from my work in HBase.
>>>
>>> Do you want this check from some particular branch-2 release? It
>>> matters since the releases along branch-2 have themselves had some
>>> noise[2].
>>>
>>> [1]: https://github.com/lvc/japi-compliance-checker
>>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>>>
>>> --
>>> busbey
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>>>
>>
>
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to
track running JDIFF on trunk and analyze results for Hadoop-common. I will
work on that and keep the JIRA and this thread updated. We need to do the
same work for YARN/MR/HDFS.
On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan <wh...@gmail.com> wrote:
> I agree with what Vinod mentioned: we need to revisit all incompatible
> changes and revert unnecessary ones. Even if we don't have any
> compatibility guarantees between 2.x and 3.x. But make user to be less
> frustrated while trying 3.x is always a better option to me.
>
> To achieve this we need to run jdiff for trunk and look at results. I
> would suggest to do this before 3.0.0-alpha1 release.
>
> In addition, for people who will try this 3-alpha1 release artifacts, a
> guide about migration from 2.x to 3.x will be very helpful, and it can also
> help for people to better understand what have changed (Just like
> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html
> )
>
> Thoughts?
>
> Thanks,
> Wangda
>
>
> On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
>> <vi...@apache.org> wrote:
>> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
>> impossible for downstreams to test incompat changes and new features
>> without a release artifact. I've been doing test builds, and
>> branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version
>> issue.
>> >
>> > Not arguing against the need for an alpha release, the question is if
>> it can wait till after 2.8 gets done.
>> >
>> > Orthogonally, do we have a report of the incompatible changes? Like the
>> one I generated for some of the branch-2 releases using late jdiff work
>> from Li Lu etc. We should do this and fix any inadvertant
>> incompatibilities. Without seeing this list of incompatibilities, why even
>> make an alpha release and force downstream components to discover issues
>> what can be identified through running reports.
>> >
>>
>> I can come up with this, atleast for Source / Binary API compatibility,
>> provided folks don't mind if I use the Java API Compliance Checker[1]
>> instead of jdiff.
>>
>> I'm already familiar with quickly using it, esp with Audience
>> Annotations from my work in HBase.
>>
>> Do you want this check from some particular branch-2 release? It
>> matters since the releases along branch-2 have themselves had some
>> noise[2].
>>
>> [1]: https://github.com/lvc/japi-compliance-checker
>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>>
>> --
>> busbey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>>
>>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to
track running JDIFF on trunk and analyze results for Hadoop-common. I will
work on that and keep the JIRA and this thread updated. We need to do the
same work for YARN/MR/HDFS.
On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan <wh...@gmail.com> wrote:
> I agree with what Vinod mentioned: we need to revisit all incompatible
> changes and revert unnecessary ones. Even if we don't have any
> compatibility guarantees between 2.x and 3.x. But make user to be less
> frustrated while trying 3.x is always a better option to me.
>
> To achieve this we need to run jdiff for trunk and look at results. I
> would suggest to do this before 3.0.0-alpha1 release.
>
> In addition, for people who will try this 3-alpha1 release artifacts, a
> guide about migration from 2.x to 3.x will be very helpful, and it can also
> help for people to better understand what have changed (Just like
> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html
> )
>
> Thoughts?
>
> Thanks,
> Wangda
>
>
> On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
>> <vi...@apache.org> wrote:
>> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
>> impossible for downstreams to test incompat changes and new features
>> without a release artifact. I've been doing test builds, and
>> branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version
>> issue.
>> >
>> > Not arguing against the need for an alpha release, the question is if
>> it can wait till after 2.8 gets done.
>> >
>> > Orthogonally, do we have a report of the incompatible changes? Like the
>> one I generated for some of the branch-2 releases using late jdiff work
>> from Li Lu etc. We should do this and fix any inadvertant
>> incompatibilities. Without seeing this list of incompatibilities, why even
>> make an alpha release and force downstream components to discover issues
>> what can be identified through running reports.
>> >
>>
>> I can come up with this, atleast for Source / Binary API compatibility,
>> provided folks don't mind if I use the Java API Compliance Checker[1]
>> instead of jdiff.
>>
>> I'm already familiar with quickly using it, esp with Audience
>> Annotations from my work in HBase.
>>
>> Do you want this check from some particular branch-2 release? It
>> matters since the releases along branch-2 have themselves had some
>> noise[2].
>>
>> [1]: https://github.com/lvc/japi-compliance-checker
>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>>
>> --
>> busbey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>>
>>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to
track running JDIFF on trunk and analyze results for Hadoop-common. I will
work on that and keep the JIRA and this thread updated. We need to do the
same work for YARN/MR/HDFS.
On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan <wh...@gmail.com> wrote:
> I agree with what Vinod mentioned: we need to revisit all incompatible
> changes and revert unnecessary ones. Even if we don't have any
> compatibility guarantees between 2.x and 3.x. But make user to be less
> frustrated while trying 3.x is always a better option to me.
>
> To achieve this we need to run jdiff for trunk and look at results. I
> would suggest to do this before 3.0.0-alpha1 release.
>
> In addition, for people who will try this 3-alpha1 release artifacts, a
> guide about migration from 2.x to 3.x will be very helpful, and it can also
> help for people to better understand what have changed (Just like
> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html
> )
>
> Thoughts?
>
> Thanks,
> Wangda
>
>
> On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
>> <vi...@apache.org> wrote:
>> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
>> impossible for downstreams to test incompat changes and new features
>> without a release artifact. I've been doing test builds, and
>> branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version
>> issue.
>> >
>> > Not arguing against the need for an alpha release, the question is if
>> it can wait till after 2.8 gets done.
>> >
>> > Orthogonally, do we have a report of the incompatible changes? Like the
>> one I generated for some of the branch-2 releases using late jdiff work
>> from Li Lu etc. We should do this and fix any inadvertant
>> incompatibilities. Without seeing this list of incompatibilities, why even
>> make an alpha release and force downstream components to discover issues
>> what can be identified through running reports.
>> >
>>
>> I can come up with this, atleast for Source / Binary API compatibility,
>> provided folks don't mind if I use the Java API Compliance Checker[1]
>> instead of jdiff.
>>
>> I'm already familiar with quickly using it, esp with Audience
>> Annotations from my work in HBase.
>>
>> Do you want this check from some particular branch-2 release? It
>> matters since the releases along branch-2 have themselves had some
>> noise[2].
>>
>> [1]: https://github.com/lvc/japi-compliance-checker
>> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>>
>> --
>> busbey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>>
>>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
I agree with what Vinod mentioned: we need to revisit all incompatible
changes and revert unnecessary ones. Even if we don't have any
compatibility guarantees between 2.x and 3.x. But make user to be less
frustrated while trying 3.x is always a better option to me.
To achieve this we need to run jdiff for trunk and look at results. I would
suggest to do this before 3.0.0-alpha1 release.
In addition, for people who will try this 3-alpha1 release artifacts, a
guide about migration from 2.x to 3.x will be very helpful, and it can also
help for people to better understand what have changed (Just like
http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html
)
Thoughts?
Thanks,
Wangda
On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
> <vi...@apache.org> wrote:
> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
> impossible for downstreams to test incompat changes and new features
> without a release artifact. I've been doing test builds, and
> branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version
> issue.
> >
> > Not arguing against the need for an alpha release, the question is if it
> can wait till after 2.8 gets done.
> >
> > Orthogonally, do we have a report of the incompatible changes? Like the
> one I generated for some of the branch-2 releases using late jdiff work
> from Li Lu etc. We should do this and fix any inadvertant
> incompatibilities. Without seeing this list of incompatibilities, why even
> make an alpha release and force downstream components to discover issues
> what can be identified through running reports.
> >
>
> I can come up with this, atleast for Source / Binary API compatibility,
> provided folks don't mind if I use the Java API Compliance Checker[1]
> instead of jdiff.
>
> I'm already familiar with quickly using it, esp with Audience
> Annotations from my work in HBase.
>
> Do you want this check from some particular branch-2 release? It
> matters since the releases along branch-2 have themselves had some
> noise[2].
>
> [1]: https://github.com/lvc/japi-compliance-checker
> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>
> --
> busbey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
I agree with what Vinod mentioned: we need to revisit all incompatible
changes and revert unnecessary ones. Even if we don't have any
compatibility guarantees between 2.x and 3.x. But make user to be less
frustrated while trying 3.x is always a better option to me.
To achieve this we need to run jdiff for trunk and look at results. I would
suggest to do this before 3.0.0-alpha1 release.
In addition, for people who will try this 3-alpha1 release artifacts, a
guide about migration from 2.x to 3.x will be very helpful, and it can also
help for people to better understand what have changed (Just like
http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html
)
Thoughts?
Thanks,
Wangda
On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
> <vi...@apache.org> wrote:
> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
> impossible for downstreams to test incompat changes and new features
> without a release artifact. I've been doing test builds, and
> branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version
> issue.
> >
> > Not arguing against the need for an alpha release, the question is if it
> can wait till after 2.8 gets done.
> >
> > Orthogonally, do we have a report of the incompatible changes? Like the
> one I generated for some of the branch-2 releases using late jdiff work
> from Li Lu etc. We should do this and fix any inadvertant
> incompatibilities. Without seeing this list of incompatibilities, why even
> make an alpha release and force downstream components to discover issues
> what can be identified through running reports.
> >
>
> I can come up with this, atleast for Source / Binary API compatibility,
> provided folks don't mind if I use the Java API Compliance Checker[1]
> instead of jdiff.
>
> I'm already familiar with quickly using it, esp with Audience
> Annotations from my work in HBase.
>
> Do you want this check from some particular branch-2 release? It
> matters since the releases along branch-2 have themselves had some
> noise[2].
>
> [1]: https://github.com/lvc/japi-compliance-checker
> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>
> --
> busbey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
I agree with what Vinod mentioned: we need to revisit all incompatible
changes and revert unnecessary ones. Even if we don't have any
compatibility guarantees between 2.x and 3.x. But make user to be less
frustrated while trying 3.x is always a better option to me.
To achieve this we need to run jdiff for trunk and look at results. I would
suggest to do this before 3.0.0-alpha1 release.
In addition, for people who will try this 3-alpha1 release artifacts, a
guide about migration from 2.x to 3.x will be very helpful, and it can also
help for people to better understand what have changed (Just like
http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html
)
Thoughts?
Thanks,
Wangda
On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
> <vi...@apache.org> wrote:
> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
> impossible for downstreams to test incompat changes and new features
> without a release artifact. I've been doing test builds, and
> branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version
> issue.
> >
> > Not arguing against the need for an alpha release, the question is if it
> can wait till after 2.8 gets done.
> >
> > Orthogonally, do we have a report of the incompatible changes? Like the
> one I generated for some of the branch-2 releases using late jdiff work
> from Li Lu etc. We should do this and fix any inadvertant
> incompatibilities. Without seeing this list of incompatibilities, why even
> make an alpha release and force downstream components to discover issues
> what can be identified through running reports.
> >
>
> I can come up with this, atleast for Source / Binary API compatibility,
> provided folks don't mind if I use the Java API Compliance Checker[1]
> instead of jdiff.
>
> I'm already familiar with quickly using it, esp with Audience
> Annotations from my work in HBase.
>
> Do you want this check from some particular branch-2 release? It
> matters since the releases along branch-2 have themselves had some
> noise[2].
>
> [1]: https://github.com/lvc/japi-compliance-checker
> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>
> --
> busbey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
<vi...@apache.org> wrote:
>> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible for downstreams to test incompat changes and new features without a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version issue.
>
> Not arguing against the need for an alpha release, the question is if it can wait till after 2.8 gets done.
>
> Orthogonally, do we have a report of the incompatible changes? Like the one I generated for some of the branch-2 releases using late jdiff work from Li Lu etc. We should do this and fix any inadvertant incompatibilities. Without seeing this list of incompatibilities, why even make an alpha release and force downstream components to discover issues what can be identified through running reports.
>
I can come up with this, atleast for Source / Binary API compatibility,
provided folks don't mind if I use the Java API Compliance Checker[1]
instead of jdiff.
I'm already familiar with quickly using it, esp with Audience
Annotations from my work in HBase.
Do you want this check from some particular branch-2 release? It
matters since the releases along branch-2 have themselves had some
noise[2].
[1]: https://github.com/lvc/japi-compliance-checker
[2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
Another reason I like the 3.0.0-alphaX approach is the ease of
communicating compatibility guarantees.
A lot of our compatibility guarantees (e.g. API/wire compat) mention
"within a major release". For the user, thinking of 3.0.0 as the beginning
of a major release seems easier than 3.2.0 being the beginning. Most users
likely will not be interested in the alphas or betas; I assume downstream
projects and early adopters are the primary targets for these pre-GA
releases.
By capturing what we mean by alpha and beta, we can communicate the
compatibility guarantees moving from alpha1 to alphaX to betaX to GA; this
applies to both the Hadoop-2 model and the 3.0.0-alphaX model.
On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I
> am not aware of any other software shipped that way. While being used by
> other software does not make an approach right, I think we should adopt an
> approach that is easy for our users to understand.
>
> The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
> proposed and okay for a long while. Do people still consider it okay? Is
> there a specific need to consider alternatives?
>
> On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
>
>> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
>> something less confusing than incompatible between 2.8/2.9 and 2.98.x
>> alphas/2.99.x betas.
>> Why not just follow our previous practice in the beginning of branch-2?
>> we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing
>> our APIs, we should bump up trunk version to 4.x for landing new
>> incompatible changes.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Karthik Kambatla <ka...@cloudera.com>
>> Sent: Monday, August 08, 2016 6:54 PM
>> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> hdfs-dev@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 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 betas leading
>> to a 3.0.0 GA. I have seen other projects use this without causing much
>> confusion.
>>
>> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <shv.hadoop@gmail.com
>> >
>> wrote:
>>
>> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> >
>> > > Hi Konst, thanks for commenting,
>> > >
>> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
>> > shv.hadoop@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.
>> > >
>> >
>> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't
>> think it
>> > went well with user perception.
>> > Say release 2.0.5-alpha turned out to be quite good even though still
>> > branded "alpha", while 2.2 was not and not branded.
>> > We should move a release to stable, when people ran it and agree it is
>> GA
>> > worthy. Otherwise you never know.
>> >
>> >
>> > >
>> > >> 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.
>> > >
>> >
>> > So the problem is in determining the latest commit, which was not
>> present
>> > in the last release, when the last release bears higher number than the
>> one
>> > being released.
>> > Interesting problem. Don't have a strong opinion on that. I guess it's
>> OK
>> > to have overlapping in changelogs.
>> > As long as we keep following the rule that commits should be made to
>> trunk
>> > first and them propagated to lower branches until the target branch is
>> > reached.
>> >
>> >
>> > >
>> > >> 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.
>> > >
>> >
>> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to
>> RM)
>> > can recut from the desired point.
>> > People were committing to branch-2 and branch-2.8 for months. And they
>> are
>> > out of sync anyways. So what's the point of the extra commit.
>> > Probably still a different thread.
>> >
>> > Thanks,
>> > --Konst
>> >
>>
>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
Another reason I like the 3.0.0-alphaX approach is the ease of
communicating compatibility guarantees.
A lot of our compatibility guarantees (e.g. API/wire compat) mention
"within a major release". For the user, thinking of 3.0.0 as the beginning
of a major release seems easier than 3.2.0 being the beginning. Most users
likely will not be interested in the alphas or betas; I assume downstream
projects and early adopters are the primary targets for these pre-GA
releases.
By capturing what we mean by alpha and beta, we can communicate the
compatibility guarantees moving from alpha1 to alphaX to betaX to GA; this
applies to both the Hadoop-2 model and the 3.0.0-alphaX model.
On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I
> am not aware of any other software shipped that way. While being used by
> other software does not make an approach right, I think we should adopt an
> approach that is easy for our users to understand.
>
> The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
> proposed and okay for a long while. Do people still consider it okay? Is
> there a specific need to consider alternatives?
>
> On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
>
>> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
>> something less confusing than incompatible between 2.8/2.9 and 2.98.x
>> alphas/2.99.x betas.
>> Why not just follow our previous practice in the beginning of branch-2?
>> we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing
>> our APIs, we should bump up trunk version to 4.x for landing new
>> incompatible changes.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Karthik Kambatla <ka...@cloudera.com>
>> Sent: Monday, August 08, 2016 6:54 PM
>> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> hdfs-dev@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 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 betas leading
>> to a 3.0.0 GA. I have seen other projects use this without causing much
>> confusion.
>>
>> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <shv.hadoop@gmail.com
>> >
>> wrote:
>>
>> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> >
>> > > Hi Konst, thanks for commenting,
>> > >
>> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
>> > shv.hadoop@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.
>> > >
>> >
>> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't
>> think it
>> > went well with user perception.
>> > Say release 2.0.5-alpha turned out to be quite good even though still
>> > branded "alpha", while 2.2 was not and not branded.
>> > We should move a release to stable, when people ran it and agree it is
>> GA
>> > worthy. Otherwise you never know.
>> >
>> >
>> > >
>> > >> 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.
>> > >
>> >
>> > So the problem is in determining the latest commit, which was not
>> present
>> > in the last release, when the last release bears higher number than the
>> one
>> > being released.
>> > Interesting problem. Don't have a strong opinion on that. I guess it's
>> OK
>> > to have overlapping in changelogs.
>> > As long as we keep following the rule that commits should be made to
>> trunk
>> > first and them propagated to lower branches until the target branch is
>> > reached.
>> >
>> >
>> > >
>> > >> 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.
>> > >
>> >
>> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to
>> RM)
>> > can recut from the desired point.
>> > People were committing to branch-2 and branch-2.8 for months. And they
>> are
>> > out of sync anyways. So what's the point of the extra commit.
>> > Probably still a different thread.
>> >
>> > Thanks,
>> > --Konst
>> >
>>
>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
Another reason I like the 3.0.0-alphaX approach is the ease of
communicating compatibility guarantees.
A lot of our compatibility guarantees (e.g. API/wire compat) mention
"within a major release". For the user, thinking of 3.0.0 as the beginning
of a major release seems easier than 3.2.0 being the beginning. Most users
likely will not be interested in the alphas or betas; I assume downstream
projects and early adopters are the primary targets for these pre-GA
releases.
By capturing what we mean by alpha and beta, we can communicate the
compatibility guarantees moving from alpha1 to alphaX to betaX to GA; this
applies to both the Hadoop-2 model and the 3.0.0-alphaX model.
On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I
> am not aware of any other software shipped that way. While being used by
> other software does not make an approach right, I think we should adopt an
> approach that is easy for our users to understand.
>
> The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
> proposed and okay for a long while. Do people still consider it okay? Is
> there a specific need to consider alternatives?
>
> On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
>
>> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
>> something less confusing than incompatible between 2.8/2.9 and 2.98.x
>> alphas/2.99.x betas.
>> Why not just follow our previous practice in the beginning of branch-2?
>> we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing
>> our APIs, we should bump up trunk version to 4.x for landing new
>> incompatible changes.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Karthik Kambatla <ka...@cloudera.com>
>> Sent: Monday, August 08, 2016 6:54 PM
>> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> hdfs-dev@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 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 betas leading
>> to a 3.0.0 GA. I have seen other projects use this without causing much
>> confusion.
>>
>> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <shv.hadoop@gmail.com
>> >
>> wrote:
>>
>> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> >
>> > > Hi Konst, thanks for commenting,
>> > >
>> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
>> > shv.hadoop@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.
>> > >
>> >
>> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't
>> think it
>> > went well with user perception.
>> > Say release 2.0.5-alpha turned out to be quite good even though still
>> > branded "alpha", while 2.2 was not and not branded.
>> > We should move a release to stable, when people ran it and agree it is
>> GA
>> > worthy. Otherwise you never know.
>> >
>> >
>> > >
>> > >> 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.
>> > >
>> >
>> > So the problem is in determining the latest commit, which was not
>> present
>> > in the last release, when the last release bears higher number than the
>> one
>> > being released.
>> > Interesting problem. Don't have a strong opinion on that. I guess it's
>> OK
>> > to have overlapping in changelogs.
>> > As long as we keep following the rule that commits should be made to
>> trunk
>> > first and them propagated to lower branches until the target branch is
>> > reached.
>> >
>> >
>> > >
>> > >> 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.
>> > >
>> >
>> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to
>> RM)
>> > can recut from the desired point.
>> > People were committing to branch-2 and branch-2.8 for months. And they
>> are
>> > out of sync anyways. So what's the point of the extra commit.
>> > Probably still a different thread.
>> >
>> > Thanks,
>> > --Konst
>> >
>>
>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
Another reason I like the 3.0.0-alphaX approach is the ease of
communicating compatibility guarantees.
A lot of our compatibility guarantees (e.g. API/wire compat) mention
"within a major release". For the user, thinking of 3.0.0 as the beginning
of a major release seems easier than 3.2.0 being the beginning. Most users
likely will not be interested in the alphas or betas; I assume downstream
projects and early adopters are the primary targets for these pre-GA
releases.
By capturing what we mean by alpha and beta, we can communicate the
compatibility guarantees moving from alpha1 to alphaX to betaX to GA; this
applies to both the Hadoop-2 model and the 3.0.0-alphaX model.
On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla <ka...@cloudera.com> wrote:
> Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I
> am not aware of any other software shipped that way. While being used by
> other software does not make an approach right, I think we should adopt an
> approach that is easy for our users to understand.
>
> The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
> proposed and okay for a long while. Do people still consider it okay? Is
> there a specific need to consider alternatives?
>
> On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
>
>> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
>> something less confusing than incompatible between 2.8/2.9 and 2.98.x
>> alphas/2.99.x betas.
>> Why not just follow our previous practice in the beginning of branch-2?
>> we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing
>> our APIs, we should bump up trunk version to 4.x for landing new
>> incompatible changes.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Karthik Kambatla <ka...@cloudera.com>
>> Sent: Monday, August 08, 2016 6:54 PM
>> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> hdfs-dev@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 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 betas leading
>> to a 3.0.0 GA. I have seen other projects use this without causing much
>> confusion.
>>
>> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <shv.hadoop@gmail.com
>> >
>> wrote:
>>
>> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> >
>> > > Hi Konst, thanks for commenting,
>> > >
>> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
>> > shv.hadoop@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.
>> > >
>> >
>> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't
>> think it
>> > went well with user perception.
>> > Say release 2.0.5-alpha turned out to be quite good even though still
>> > branded "alpha", while 2.2 was not and not branded.
>> > We should move a release to stable, when people ran it and agree it is
>> GA
>> > worthy. Otherwise you never know.
>> >
>> >
>> > >
>> > >> 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.
>> > >
>> >
>> > So the problem is in determining the latest commit, which was not
>> present
>> > in the last release, when the last release bears higher number than the
>> one
>> > being released.
>> > Interesting problem. Don't have a strong opinion on that. I guess it's
>> OK
>> > to have overlapping in changelogs.
>> > As long as we keep following the rule that commits should be made to
>> trunk
>> > first and them propagated to lower branches until the target branch is
>> > reached.
>> >
>> >
>> > >
>> > >> 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.
>> > >
>> >
>> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to
>> RM)
>> > can recut from the desired point.
>> > People were committing to branch-2 and branch-2.8 for months. And they
>> are
>> > out of sync anyways. So what's the point of the extra commit.
>> > Probably still a different thread.
>> >
>> > Thanks,
>> > --Konst
>> >
>>
>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I am
not aware of any other software shipped that way. While being used by other
software does not make an approach right, I think we should adopt an
approach that is easy for our users to understand.
The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
proposed and okay for a long while. Do people still consider it okay? Is
there a specific need to consider alternatives?
On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
> something less confusing than incompatible between 2.8/2.9 and 2.98.x
> alphas/2.99.x betas.
> Why not just follow our previous practice in the beginning of branch-2? we
> can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our
> APIs, we should bump up trunk version to 4.x for landing new incompatible
> changes.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Karthik Kambatla <ka...@cloudera.com>
> Sent: Monday, August 08, 2016 6:54 PM
> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> hdfs-dev@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 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 betas leading
> to a 3.0.0 GA. I have seen other projects use this without causing much
> confusion.
>
> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> > wrote:
> >
> > > Hi Konst, thanks for commenting,
> > >
> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> > shv.hadoop@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.
> > >
> >
> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't think
> it
> > went well with user perception.
> > Say release 2.0.5-alpha turned out to be quite good even though still
> > branded "alpha", while 2.2 was not and not branded.
> > We should move a release to stable, when people ran it and agree it is GA
> > worthy. Otherwise you never know.
> >
> >
> > >
> > >> 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.
> > >
> >
> > So the problem is in determining the latest commit, which was not present
> > in the last release, when the last release bears higher number than the
> one
> > being released.
> > Interesting problem. Don't have a strong opinion on that. I guess it's OK
> > to have overlapping in changelogs.
> > As long as we keep following the rule that commits should be made to
> trunk
> > first and them propagated to lower branches until the target branch is
> > reached.
> >
> >
> > >
> > >> 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.
> > >
> >
> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> > can recut from the desired point.
> > People were committing to branch-2 and branch-2.8 for months. And they
> are
> > out of sync anyways. So what's the point of the extra commit.
> > Probably still a different thread.
> >
> > Thanks,
> > --Konst
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I am
not aware of any other software shipped that way. While being used by other
software does not make an approach right, I think we should adopt an
approach that is easy for our users to understand.
The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
proposed and okay for a long while. Do people still consider it okay? Is
there a specific need to consider alternatives?
On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
> something less confusing than incompatible between 2.8/2.9 and 2.98.x
> alphas/2.99.x betas.
> Why not just follow our previous practice in the beginning of branch-2? we
> can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our
> APIs, we should bump up trunk version to 4.x for landing new incompatible
> changes.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Karthik Kambatla <ka...@cloudera.com>
> Sent: Monday, August 08, 2016 6:54 PM
> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> hdfs-dev@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 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 betas leading
> to a 3.0.0 GA. I have seen other projects use this without causing much
> confusion.
>
> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> > wrote:
> >
> > > Hi Konst, thanks for commenting,
> > >
> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> > shv.hadoop@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.
> > >
> >
> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't think
> it
> > went well with user perception.
> > Say release 2.0.5-alpha turned out to be quite good even though still
> > branded "alpha", while 2.2 was not and not branded.
> > We should move a release to stable, when people ran it and agree it is GA
> > worthy. Otherwise you never know.
> >
> >
> > >
> > >> 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.
> > >
> >
> > So the problem is in determining the latest commit, which was not present
> > in the last release, when the last release bears higher number than the
> one
> > being released.
> > Interesting problem. Don't have a strong opinion on that. I guess it's OK
> > to have overlapping in changelogs.
> > As long as we keep following the rule that commits should be made to
> trunk
> > first and them propagated to lower branches until the target branch is
> > reached.
> >
> >
> > >
> > >> 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.
> > >
> >
> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> > can recut from the desired point.
> > People were committing to branch-2 and branch-2.8 for months. And they
> are
> > out of sync anyways. So what's the point of the extra commit.
> > Probably still a different thread.
> >
> > Thanks,
> > --Konst
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I am
not aware of any other software shipped that way. While being used by other
software does not make an approach right, I think we should adopt an
approach that is easy for our users to understand.
The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
proposed and okay for a long while. Do people still consider it okay? Is
there a specific need to consider alternatives?
On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
> something less confusing than incompatible between 2.8/2.9 and 2.98.x
> alphas/2.99.x betas.
> Why not just follow our previous practice in the beginning of branch-2? we
> can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our
> APIs, we should bump up trunk version to 4.x for landing new incompatible
> changes.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Karthik Kambatla <ka...@cloudera.com>
> Sent: Monday, August 08, 2016 6:54 PM
> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> hdfs-dev@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 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 betas leading
> to a 3.0.0 GA. I have seen other projects use this without causing much
> confusion.
>
> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> > wrote:
> >
> > > Hi Konst, thanks for commenting,
> > >
> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> > shv.hadoop@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.
> > >
> >
> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't think
> it
> > went well with user perception.
> > Say release 2.0.5-alpha turned out to be quite good even though still
> > branded "alpha", while 2.2 was not and not branded.
> > We should move a release to stable, when people ran it and agree it is GA
> > worthy. Otherwise you never know.
> >
> >
> > >
> > >> 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.
> > >
> >
> > So the problem is in determining the latest commit, which was not present
> > in the last release, when the last release bears higher number than the
> one
> > being released.
> > Interesting problem. Don't have a strong opinion on that. I guess it's OK
> > to have overlapping in changelogs.
> > As long as we keep following the rule that commits should be made to
> trunk
> > first and them propagated to lower branches until the target branch is
> > reached.
> >
> >
> > >
> > >> 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.
> > >
> >
> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> > can recut from the desired point.
> > People were committing to branch-2 and branch-2.8 for months. And they
> are
> > out of sync anyways. So what's the point of the extra commit.
> > Probably still a different thread.
> >
> > Thanks,
> > --Konst
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I am
not aware of any other software shipped that way. While being used by other
software does not make an approach right, I think we should adopt an
approach that is easy for our users to understand.
The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
proposed and okay for a long while. Do people still consider it okay? Is
there a specific need to consider alternatives?
On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
> something less confusing than incompatible between 2.8/2.9 and 2.98.x
> alphas/2.99.x betas.
> Why not just follow our previous practice in the beginning of branch-2? we
> can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our
> APIs, we should bump up trunk version to 4.x for landing new incompatible
> changes.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Karthik Kambatla <ka...@cloudera.com>
> Sent: Monday, August 08, 2016 6:54 PM
> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> hdfs-dev@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 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 betas leading
> to a 3.0.0 GA. I have seen other projects use this without causing much
> confusion.
>
> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> > wrote:
> >
> > > Hi Konst, thanks for commenting,
> > >
> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> > shv.hadoop@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.
> > >
> >
> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't think
> it
> > went well with user perception.
> > Say release 2.0.5-alpha turned out to be quite good even though still
> > branded "alpha", while 2.2 was not and not branded.
> > We should move a release to stable, when people ran it and agree it is GA
> > worthy. Otherwise you never know.
> >
> >
> > >
> > >> 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.
> > >
> >
> > So the problem is in determining the latest commit, which was not present
> > in the last release, when the last release bears higher number than the
> one
> > being released.
> > Interesting problem. Don't have a strong opinion on that. I guess it's OK
> > to have overlapping in changelogs.
> > As long as we keep following the rule that commits should be made to
> trunk
> > first and them propagated to lower branches until the target branch is
> > reached.
> >
> >
> > >
> > >> 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.
> > >
> >
> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> > can recut from the desired point.
> > People were committing to branch-2 and branch-2.8 for months. And they
> are
> > out of sync anyways. So what's the point of the extra commit.
> > Probably still a different thread.
> >
> > Thanks,
> > --Konst
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Junping Du <jd...@hortonworks.com>.
I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is something less confusing than incompatible between 2.8/2.9 and 2.98.x alphas/2.99.x betas.
Why not just follow our previous practice in the beginning of branch-2? we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our APIs, we should bump up trunk version to 4.x for landing new incompatible changes.
Thanks,
Junping
________________________________________
From: Karthik Kambatla <ka...@cloudera.com>
Sent: Monday, August 08, 2016 6:54 PM
Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@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 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 betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.
On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:
> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@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.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 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.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 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.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Junping Du <jd...@hortonworks.com>.
I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is something less confusing than incompatible between 2.8/2.9 and 2.98.x alphas/2.99.x betas.
Why not just follow our previous practice in the beginning of branch-2? we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our APIs, we should bump up trunk version to 4.x for landing new incompatible changes.
Thanks,
Junping
________________________________________
From: Karthik Kambatla <ka...@cloudera.com>
Sent: Monday, August 08, 2016 6:54 PM
Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@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 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 betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.
On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:
> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@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.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 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.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 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.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Junping Du <jd...@hortonworks.com>.
I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is something less confusing than incompatible between 2.8/2.9 and 2.98.x alphas/2.99.x betas.
Why not just follow our previous practice in the beginning of branch-2? we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our APIs, we should bump up trunk version to 4.x for landing new incompatible changes.
Thanks,
Junping
________________________________________
From: Karthik Kambatla <ka...@cloudera.com>
Sent: Monday, August 08, 2016 6:54 PM
Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@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 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 betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.
On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:
> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@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.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 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.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 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.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Junping Du <jd...@hortonworks.com>.
I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is something less confusing than incompatible between 2.8/2.9 and 2.98.x alphas/2.99.x betas.
Why not just follow our previous practice in the beginning of branch-2? we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our APIs, we should bump up trunk version to 4.x for landing new incompatible changes.
Thanks,
Junping
________________________________________
From: Karthik Kambatla <ka...@cloudera.com>
Sent: Monday, August 08, 2016 6:54 PM
Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@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 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 betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.
On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:
> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@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.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 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.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 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.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
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 betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.
On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:
> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@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.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 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.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 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.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
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 betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.
On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:
> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@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.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 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.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 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.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
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 betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.
On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:
> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@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.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 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.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 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.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
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 betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.
On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:
> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@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.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 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.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 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.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Konstantin Shvachko <sh...@gmail.com>.
On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <shv.hadoop@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.
>
As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
went well with user perception.
Say release 2.0.5-alpha turned out to be quite good even though still
branded "alpha", while 2.2 was not and not branded.
We should move a release to stable, when people ran it and agree it is GA
worthy. Otherwise you never know.
>
>> 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.
>
So the problem is in determining the latest commit, which was not present
in the last release, when the last release bears higher number than the one
being released.
Interesting problem. Don't have a strong opinion on that. I guess it's OK
to have overlapping in changelogs.
As long as we keep following the rule that commits should be made to trunk
first and them propagated to lower branches until the target branch is
reached.
>
>> 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.
>
Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
can recut from the desired point.
People were committing to branch-2 and branch-2.8 for months. And they are
out of sync anyways. So what's the point of the extra commit.
Probably still a different thread.
Thanks,
--Konst
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Konstantin Shvachko <sh...@gmail.com>.
On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <shv.hadoop@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.
>
As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
went well with user perception.
Say release 2.0.5-alpha turned out to be quite good even though still
branded "alpha", while 2.2 was not and not branded.
We should move a release to stable, when people ran it and agree it is GA
worthy. Otherwise you never know.
>
>> 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.
>
So the problem is in determining the latest commit, which was not present
in the last release, when the last release bears higher number than the one
being released.
Interesting problem. Don't have a strong opinion on that. I guess it's OK
to have overlapping in changelogs.
As long as we keep following the rule that commits should be made to trunk
first and them propagated to lower branches until the target branch is
reached.
>
>> 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.
>
Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
can recut from the desired point.
People were committing to branch-2 and branch-2.8 for months. And they are
out of sync anyways. So what's the point of the extra commit.
Probably still a different thread.
Thanks,
--Konst
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Chris Douglas <cd...@apache.org>.
> 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. Conversely, I've
> met people who were confused by the 2.0/2.1/2.2 progression. As far as I
> know, we were unique in using this style of versioning.
Yes, but even after a stable release, we haven't blocked new (or
incompatible) features in minor releases. Some minor releases- 0.16,
0.21, 2.6.0- included complicated features that took awhile to
stabilize. Most of our x.y.0 releases are not stable, because
downstream reports come back only after we cut a release. Signaling
stability is useful, but this identifier is not reliable. At least,
it's less reliable than a section on the website recommending the
latest stable release beside alpha/beta versions.
Anyway- if we do use this, then we can use Maven's schema:
<major>.<minor>.<patch>-<identifier>-<build number>
Though I hope we won't need it, starting with 3.0.0-alpha-01 will
avoid -alpha10 as preceding -alpha2. We've discussed it enough; I'll
let it go.
> I also think what we're doing now *is* considered releasing from trunk.
> Maybe I'm missing something, but we can't literally release from trunk
> without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
> until the release or change fix versions afterwards.
We're not constrained on where we cut releases. If subsequent releases
will be off of trunk- not the -alpha branch- and we aren't
removing/holding any change until stabilizing at -beta, then we don't
need to maintain a separate release branch concurrent with development
on trunk. Bumping the release version, etc. might be useful, but a
living branch just mixes up the lineage and adds steps to commit
(trunk > 3.0.0-alpha > branch-2 > branch-2.8 > ...). If it's easier
for you to create the RC then OK. -C
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Chris Douglas <cd...@apache.org>.
> 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. Conversely, I've
> met people who were confused by the 2.0/2.1/2.2 progression. As far as I
> know, we were unique in using this style of versioning.
Yes, but even after a stable release, we haven't blocked new (or
incompatible) features in minor releases. Some minor releases- 0.16,
0.21, 2.6.0- included complicated features that took awhile to
stabilize. Most of our x.y.0 releases are not stable, because
downstream reports come back only after we cut a release. Signaling
stability is useful, but this identifier is not reliable. At least,
it's less reliable than a section on the website recommending the
latest stable release beside alpha/beta versions.
Anyway- if we do use this, then we can use Maven's schema:
<major>.<minor>.<patch>-<identifier>-<build number>
Though I hope we won't need it, starting with 3.0.0-alpha-01 will
avoid -alpha10 as preceding -alpha2. We've discussed it enough; I'll
let it go.
> I also think what we're doing now *is* considered releasing from trunk.
> Maybe I'm missing something, but we can't literally release from trunk
> without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
> until the release or change fix versions afterwards.
We're not constrained on where we cut releases. If subsequent releases
will be off of trunk- not the -alpha branch- and we aren't
removing/holding any change until stabilizing at -beta, then we don't
need to maintain a separate release branch concurrent with development
on trunk. Bumping the release version, etc. might be useful, but a
living branch just mixes up the lineage and adds steps to commit
(trunk > 3.0.0-alpha > branch-2 > branch-2.8 > ...). If it's easier
for you to create the RC then OK. -C
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Chris Douglas <cd...@apache.org>.
> 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. Conversely, I've
> met people who were confused by the 2.0/2.1/2.2 progression. As far as I
> know, we were unique in using this style of versioning.
Yes, but even after a stable release, we haven't blocked new (or
incompatible) features in minor releases. Some minor releases- 0.16,
0.21, 2.6.0- included complicated features that took awhile to
stabilize. Most of our x.y.0 releases are not stable, because
downstream reports come back only after we cut a release. Signaling
stability is useful, but this identifier is not reliable. At least,
it's less reliable than a section on the website recommending the
latest stable release beside alpha/beta versions.
Anyway- if we do use this, then we can use Maven's schema:
<major>.<minor>.<patch>-<identifier>-<build number>
Though I hope we won't need it, starting with 3.0.0-alpha-01 will
avoid -alpha10 as preceding -alpha2. We've discussed it enough; I'll
let it go.
> I also think what we're doing now *is* considered releasing from trunk.
> Maybe I'm missing something, but we can't literally release from trunk
> without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
> until the release or change fix versions afterwards.
We're not constrained on where we cut releases. If subsequent releases
will be off of trunk- not the -alpha branch- and we aren't
removing/holding any change until stabilizing at -beta, then we don't
need to maintain a separate release branch concurrent with development
on trunk. Bumping the release version, etc. might be useful, but a
living branch just mixes up the lineage and adds steps to commit
(trunk > 3.0.0-alpha > branch-2 > branch-2.8 > ...). If it's easier
for you to create the RC then OK. -C
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Chris Douglas <cd...@apache.org>.
> 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. Conversely, I've
> met people who were confused by the 2.0/2.1/2.2 progression. As far as I
> know, we were unique in using this style of versioning.
Yes, but even after a stable release, we haven't blocked new (or
incompatible) features in minor releases. Some minor releases- 0.16,
0.21, 2.6.0- included complicated features that took awhile to
stabilize. Most of our x.y.0 releases are not stable, because
downstream reports come back only after we cut a release. Signaling
stability is useful, but this identifier is not reliable. At least,
it's less reliable than a section on the website recommending the
latest stable release beside alpha/beta versions.
Anyway- if we do use this, then we can use Maven's schema:
<major>.<minor>.<patch>-<identifier>-<build number>
Though I hope we won't need it, starting with 3.0.0-alpha-01 will
avoid -alpha10 as preceding -alpha2. We've discussed it enough; I'll
let it go.
> I also think what we're doing now *is* considered releasing from trunk.
> Maybe I'm missing something, but we can't literally release from trunk
> without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
> until the release or change fix versions afterwards.
We're not constrained on where we cut releases. If subsequent releases
will be off of trunk- not the -alpha branch- and we aren't
removing/holding any change until stabilizing at -beta, then we don't
need to maintain a separate release branch concurrent with development
on trunk. Bumping the release version, etc. might be useful, but a
living branch just mixes up the lineage and adds steps to commit
(trunk > 3.0.0-alpha > branch-2 > branch-2.8 > ...). If it's easier
for you to create the RC then OK. -C
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas <cd...@apache.org> 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 JIRA tagging, in packaging...
>
> 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. Conversely, I've
met people who were confused by the 2.0/2.1/2.2 progression. As far as I
know, we were unique in using this style of versioning.
I also think what we're doing now *is* considered releasing from trunk.
Maybe I'm missing something, but we can't literally release from trunk
without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
until the release or change fix versions afterwards.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas <cd...@apache.org> 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 JIRA tagging, in packaging...
>
> 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. Conversely, I've
met people who were confused by the 2.0/2.1/2.2 progression. As far as I
know, we were unique in using this style of versioning.
I also think what we're doing now *is* considered releasing from trunk.
Maybe I'm missing something, but we can't literally release from trunk
without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
until the release or change fix versions afterwards.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas <cd...@apache.org> 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 JIRA tagging, in packaging...
>
> 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. Conversely, I've
met people who were confused by the 2.0/2.1/2.2 progression. As far as I
know, we were unique in using this style of versioning.
I also think what we're doing now *is* considered releasing from trunk.
Maybe I'm missing something, but we can't literally release from trunk
without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
until the release or change fix versions afterwards.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas <cd...@apache.org> 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 JIRA tagging, in packaging...
>
> 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. Conversely, I've
met people who were confused by the 2.0/2.1/2.2 progression. As far as I
know, we were unique in using this style of versioning.
I also think what we're doing now *is* considered releasing from trunk.
Maybe I'm missing something, but we can't literally release from trunk
without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
until the release or change fix versions afterwards.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Chris Douglas <cd...@apache.org>.
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 <an...@cloudera.com> wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Konstantin Shvachko <sh...@gmail.com>.
On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <shv.hadoop@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.
>
As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
went well with user perception.
Say release 2.0.5-alpha turned out to be quite good even though still
branded "alpha", while 2.2 was not and not branded.
We should move a release to stable, when people ran it and agree it is GA
worthy. Otherwise you never know.
>
>> 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.
>
So the problem is in determining the latest commit, which was not present
in the last release, when the last release bears higher number than the one
being released.
Interesting problem. Don't have a strong opinion on that. I guess it's OK
to have overlapping in changelogs.
As long as we keep following the rule that commits should be made to trunk
first and them propagated to lower branches until the target branch is
reached.
>
>> 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.
>
Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
can recut from the desired point.
People were committing to branch-2 and branch-2.8 for months. And they are
out of sync anyways. So what's the point of the extra commit.
Probably still a different thread.
Thanks,
--Konst
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Konstantin Shvachko <sh...@gmail.com>.
On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <shv.hadoop@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.
>
As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
went well with user perception.
Say release 2.0.5-alpha turned out to be quite good even though still
branded "alpha", while 2.2 was not and not branded.
We should move a release to stable, when people ran it and agree it is GA
worthy. Otherwise you never know.
>
>> 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.
>
So the problem is in determining the latest commit, which was not present
in the last release, when the last release bears higher number than the one
being released.
Interesting problem. Don't have a strong opinion on that. I guess it's OK
to have overlapping in changelogs.
As long as we keep following the rule that commits should be made to trunk
first and them propagated to lower branches until the target branch is
reached.
>
>> 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.
>
Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
can recut from the desired point.
People were committing to branch-2 and branch-2.8 for months. And they are
out of sync anyways. So what's the point of the extra commit.
Probably still a different thread.
Thanks,
--Konst
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Chris Douglas <cd...@apache.org>.
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 <an...@cloudera.com> wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Chris Douglas <cd...@apache.org>.
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 <an...@cloudera.com> wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@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: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Chris Douglas <cd...@apache.org>.
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 <an...@cloudera.com> wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@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: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Hi Konst, thanks for commenting,
On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@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
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Hi Konst, thanks for commenting,
On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@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
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Hi Konst, thanks for commenting,
On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@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
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Hi Konst, thanks for commenting,
On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@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
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Konstantin Shvachko <sh...@gmail.com>.
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.
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.
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.
Thanks,
--Konstantin
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
>
> 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?
>
>
Yea. It means the if you're coming from 2.7, you'd read the 3.0.0-alphas,
3.0.0-betas, and finally the 3.0.0 GA notes.
The website notes will aggregate all the alpha and beta changes leading up
to 3.0.0 GA, so is likely where users will turn to first.
>
>> 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?
>
>
Yea, I have a script and some JIRA queries that can help with this. I'll
also plan to compare with git log contents for extra verification.
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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 vacation until the 15th, but will
tackle this when I get back. The bulk updates will also be floowed with a
wide-distribution email reminder about how to appropriately set fix
versions.
Best,
Andrew
On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang <an...@cloudera.com>
wrote:
> 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
>
> Ping me if you'd like edit/comment privs, or send comments to this thread.
>
> I'm eager to close on this so we can keeping pushing on the 2.8.0 and
> 3.0.0-alpha1 releases. I'd like to post this content somewhere official
> early next week, so if you have additional feedback, please keep it coming.
>
> Best,
> Andrew
>
> On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
>> 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
>>>> misunderstanding the risky here.
>>>>
>>>
>>> These are the definitions of "alpha" and "beta" used leading up to the
>>> 2.2 GA release, so it's not something new. These are also the normal
>>> industry definitions. Alpha means no API compatibility guarantees, early
>>> software. Beta means API compatible, but still some bugs.
>>>
>>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>>> releases post-2.2 GA. The thinking was that everything after would be
>>> compatible and thus (at the least) never alpha. I think this is why the
>>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>>> we could have just called 2.7.0 "beta".
>>>
>>> I think this would be good to have in our compat guidelines or
>>> somewhere. Happy to work with Karthik/Vinod/others on this.
>>>
>>
>> I am not sure if we formally defined the terms "alpha" and "beta" for
>> Hadoop 2, but my understanding of them agrees with the general definitions
>> on the web.
>>
>> Alpha:
>>
>> - Early version for testing - integration with downstream, deployment
>> etc.
>> - Not feature complete
>> - No compatibility guarantees yet
>>
>> Beta:
>>
>> - Feature complete
>> - API compatibility guaranteed
>> - Need clear definition for other kinds of compatibility (wire,
>> client-dependencies, server-dependencies etc.)
>> - Not ready for production deployments
>>
>> GA
>>
>> - Ready for production
>> - All the usual compatibility guarantees apply.
>>
>> If there is general agreement, I can work towards getting this into our
>> documentation.
>>
>>
>>>
>>>> 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.
>>>>
>>>> While we're still in alpha for 3.0.0, there's no need for a separate
>>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>>
>>
>> Branching at beta time seems reasonable.
>>
>> Overall, are there any incompatible changes on trunk that we wouldn't be
>> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
>> those bits ever?
>>
>>
>>>
>>> Best,
>>> Andrew
>>>
>>
>>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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 vacation until the 15th, but will
tackle this when I get back. The bulk updates will also be floowed with a
wide-distribution email reminder about how to appropriately set fix
versions.
Best,
Andrew
On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang <an...@cloudera.com>
wrote:
> 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
>
> Ping me if you'd like edit/comment privs, or send comments to this thread.
>
> I'm eager to close on this so we can keeping pushing on the 2.8.0 and
> 3.0.0-alpha1 releases. I'd like to post this content somewhere official
> early next week, so if you have additional feedback, please keep it coming.
>
> Best,
> Andrew
>
> On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
>> 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
>>>> misunderstanding the risky here.
>>>>
>>>
>>> These are the definitions of "alpha" and "beta" used leading up to the
>>> 2.2 GA release, so it's not something new. These are also the normal
>>> industry definitions. Alpha means no API compatibility guarantees, early
>>> software. Beta means API compatible, but still some bugs.
>>>
>>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>>> releases post-2.2 GA. The thinking was that everything after would be
>>> compatible and thus (at the least) never alpha. I think this is why the
>>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>>> we could have just called 2.7.0 "beta".
>>>
>>> I think this would be good to have in our compat guidelines or
>>> somewhere. Happy to work with Karthik/Vinod/others on this.
>>>
>>
>> I am not sure if we formally defined the terms "alpha" and "beta" for
>> Hadoop 2, but my understanding of them agrees with the general definitions
>> on the web.
>>
>> Alpha:
>>
>> - Early version for testing - integration with downstream, deployment
>> etc.
>> - Not feature complete
>> - No compatibility guarantees yet
>>
>> Beta:
>>
>> - Feature complete
>> - API compatibility guaranteed
>> - Need clear definition for other kinds of compatibility (wire,
>> client-dependencies, server-dependencies etc.)
>> - Not ready for production deployments
>>
>> GA
>>
>> - Ready for production
>> - All the usual compatibility guarantees apply.
>>
>> If there is general agreement, I can work towards getting this into our
>> documentation.
>>
>>
>>>
>>>> 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.
>>>>
>>>> While we're still in alpha for 3.0.0, there's no need for a separate
>>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>>
>>
>> Branching at beta time seems reasonable.
>>
>> Overall, are there any incompatible changes on trunk that we wouldn't be
>> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
>> those bits ever?
>>
>>
>>>
>>> Best,
>>> Andrew
>>>
>>
>>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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 vacation until the 15th, but will
tackle this when I get back. The bulk updates will also be floowed with a
wide-distribution email reminder about how to appropriately set fix
versions.
Best,
Andrew
On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang <an...@cloudera.com>
wrote:
> 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
>
> Ping me if you'd like edit/comment privs, or send comments to this thread.
>
> I'm eager to close on this so we can keeping pushing on the 2.8.0 and
> 3.0.0-alpha1 releases. I'd like to post this content somewhere official
> early next week, so if you have additional feedback, please keep it coming.
>
> Best,
> Andrew
>
> On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
>> 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
>>>> misunderstanding the risky here.
>>>>
>>>
>>> These are the definitions of "alpha" and "beta" used leading up to the
>>> 2.2 GA release, so it's not something new. These are also the normal
>>> industry definitions. Alpha means no API compatibility guarantees, early
>>> software. Beta means API compatible, but still some bugs.
>>>
>>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>>> releases post-2.2 GA. The thinking was that everything after would be
>>> compatible and thus (at the least) never alpha. I think this is why the
>>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>>> we could have just called 2.7.0 "beta".
>>>
>>> I think this would be good to have in our compat guidelines or
>>> somewhere. Happy to work with Karthik/Vinod/others on this.
>>>
>>
>> I am not sure if we formally defined the terms "alpha" and "beta" for
>> Hadoop 2, but my understanding of them agrees with the general definitions
>> on the web.
>>
>> Alpha:
>>
>> - Early version for testing - integration with downstream, deployment
>> etc.
>> - Not feature complete
>> - No compatibility guarantees yet
>>
>> Beta:
>>
>> - Feature complete
>> - API compatibility guaranteed
>> - Need clear definition for other kinds of compatibility (wire,
>> client-dependencies, server-dependencies etc.)
>> - Not ready for production deployments
>>
>> GA
>>
>> - Ready for production
>> - All the usual compatibility guarantees apply.
>>
>> If there is general agreement, I can work towards getting this into our
>> documentation.
>>
>>
>>>
>>>> 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.
>>>>
>>>> While we're still in alpha for 3.0.0, there's no need for a separate
>>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>>
>>
>> Branching at beta time seems reasonable.
>>
>> Overall, are there any incompatible changes on trunk that we wouldn't be
>> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
>> those bits ever?
>>
>>
>>>
>>> Best,
>>> Andrew
>>>
>>
>>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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 vacation until the 15th, but will
tackle this when I get back. The bulk updates will also be floowed with a
wide-distribution email reminder about how to appropriately set fix
versions.
Best,
Andrew
On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang <an...@cloudera.com>
wrote:
> 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
>
> Ping me if you'd like edit/comment privs, or send comments to this thread.
>
> I'm eager to close on this so we can keeping pushing on the 2.8.0 and
> 3.0.0-alpha1 releases. I'd like to post this content somewhere official
> early next week, so if you have additional feedback, please keep it coming.
>
> Best,
> Andrew
>
> On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
>> 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
>>>> misunderstanding the risky here.
>>>>
>>>
>>> These are the definitions of "alpha" and "beta" used leading up to the
>>> 2.2 GA release, so it's not something new. These are also the normal
>>> industry definitions. Alpha means no API compatibility guarantees, early
>>> software. Beta means API compatible, but still some bugs.
>>>
>>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>>> releases post-2.2 GA. The thinking was that everything after would be
>>> compatible and thus (at the least) never alpha. I think this is why the
>>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>>> we could have just called 2.7.0 "beta".
>>>
>>> I think this would be good to have in our compat guidelines or
>>> somewhere. Happy to work with Karthik/Vinod/others on this.
>>>
>>
>> I am not sure if we formally defined the terms "alpha" and "beta" for
>> Hadoop 2, but my understanding of them agrees with the general definitions
>> on the web.
>>
>> Alpha:
>>
>> - Early version for testing - integration with downstream, deployment
>> etc.
>> - Not feature complete
>> - No compatibility guarantees yet
>>
>> Beta:
>>
>> - Feature complete
>> - API compatibility guaranteed
>> - Need clear definition for other kinds of compatibility (wire,
>> client-dependencies, server-dependencies etc.)
>> - Not ready for production deployments
>>
>> GA
>>
>> - Ready for production
>> - All the usual compatibility guarantees apply.
>>
>> If there is general agreement, I can work towards getting this into our
>> documentation.
>>
>>
>>>
>>>> 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.
>>>>
>>>> While we're still in alpha for 3.0.0, there's no need for a separate
>>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>>
>>
>> Branching at beta time seems reasonable.
>>
>> Overall, are there any incompatible changes on trunk that we wouldn't be
>> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
>> those bits ever?
>>
>>
>>>
>>> Best,
>>> Andrew
>>>
>>
>>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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
Ping me if you'd like edit/comment privs, or send comments to this thread.
I'm eager to close on this so we can keeping pushing on the 2.8.0 and
3.0.0-alpha1 releases. I'd like to post this content somewhere official
early next week, so if you have additional feedback, please keep it coming.
Best,
Andrew
On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> 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
>>> misunderstanding the risky here.
>>>
>>
>> These are the definitions of "alpha" and "beta" used leading up to the
>> 2.2 GA release, so it's not something new. These are also the normal
>> industry definitions. Alpha means no API compatibility guarantees, early
>> software. Beta means API compatible, but still some bugs.
>>
>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>> releases post-2.2 GA. The thinking was that everything after would be
>> compatible and thus (at the least) never alpha. I think this is why the
>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>> we could have just called 2.7.0 "beta".
>>
>> I think this would be good to have in our compat guidelines or somewhere.
>> Happy to work with Karthik/Vinod/others on this.
>>
>
> I am not sure if we formally defined the terms "alpha" and "beta" for
> Hadoop 2, but my understanding of them agrees with the general definitions
> on the web.
>
> Alpha:
>
> - Early version for testing - integration with downstream, deployment
> etc.
> - Not feature complete
> - No compatibility guarantees yet
>
> Beta:
>
> - Feature complete
> - API compatibility guaranteed
> - Need clear definition for other kinds of compatibility (wire,
> client-dependencies, server-dependencies etc.)
> - Not ready for production deployments
>
> GA
>
> - Ready for production
> - All the usual compatibility guarantees apply.
>
> If there is general agreement, I can work towards getting this into our
> documentation.
>
>
>>
>>> 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.
>>>
>>> While we're still in alpha for 3.0.0, there's no need for a separate
>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>
>
> Branching at beta time seems reasonable.
>
> Overall, are there any incompatible changes on trunk that we wouldn't be
> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
> those bits ever?
>
>
>>
>> Best,
>> Andrew
>>
>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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
Ping me if you'd like edit/comment privs, or send comments to this thread.
I'm eager to close on this so we can keeping pushing on the 2.8.0 and
3.0.0-alpha1 releases. I'd like to post this content somewhere official
early next week, so if you have additional feedback, please keep it coming.
Best,
Andrew
On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> 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
>>> misunderstanding the risky here.
>>>
>>
>> These are the definitions of "alpha" and "beta" used leading up to the
>> 2.2 GA release, so it's not something new. These are also the normal
>> industry definitions. Alpha means no API compatibility guarantees, early
>> software. Beta means API compatible, but still some bugs.
>>
>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>> releases post-2.2 GA. The thinking was that everything after would be
>> compatible and thus (at the least) never alpha. I think this is why the
>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>> we could have just called 2.7.0 "beta".
>>
>> I think this would be good to have in our compat guidelines or somewhere.
>> Happy to work with Karthik/Vinod/others on this.
>>
>
> I am not sure if we formally defined the terms "alpha" and "beta" for
> Hadoop 2, but my understanding of them agrees with the general definitions
> on the web.
>
> Alpha:
>
> - Early version for testing - integration with downstream, deployment
> etc.
> - Not feature complete
> - No compatibility guarantees yet
>
> Beta:
>
> - Feature complete
> - API compatibility guaranteed
> - Need clear definition for other kinds of compatibility (wire,
> client-dependencies, server-dependencies etc.)
> - Not ready for production deployments
>
> GA
>
> - Ready for production
> - All the usual compatibility guarantees apply.
>
> If there is general agreement, I can work towards getting this into our
> documentation.
>
>
>>
>>> 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.
>>>
>>> While we're still in alpha for 3.0.0, there's no need for a separate
>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>
>
> Branching at beta time seems reasonable.
>
> Overall, are there any incompatible changes on trunk that we wouldn't be
> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
> those bits ever?
>
>
>>
>> Best,
>> Andrew
>>
>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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
Ping me if you'd like edit/comment privs, or send comments to this thread.
I'm eager to close on this so we can keeping pushing on the 2.8.0 and
3.0.0-alpha1 releases. I'd like to post this content somewhere official
early next week, so if you have additional feedback, please keep it coming.
Best,
Andrew
On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> 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
>>> misunderstanding the risky here.
>>>
>>
>> These are the definitions of "alpha" and "beta" used leading up to the
>> 2.2 GA release, so it's not something new. These are also the normal
>> industry definitions. Alpha means no API compatibility guarantees, early
>> software. Beta means API compatible, but still some bugs.
>>
>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>> releases post-2.2 GA. The thinking was that everything after would be
>> compatible and thus (at the least) never alpha. I think this is why the
>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>> we could have just called 2.7.0 "beta".
>>
>> I think this would be good to have in our compat guidelines or somewhere.
>> Happy to work with Karthik/Vinod/others on this.
>>
>
> I am not sure if we formally defined the terms "alpha" and "beta" for
> Hadoop 2, but my understanding of them agrees with the general definitions
> on the web.
>
> Alpha:
>
> - Early version for testing - integration with downstream, deployment
> etc.
> - Not feature complete
> - No compatibility guarantees yet
>
> Beta:
>
> - Feature complete
> - API compatibility guaranteed
> - Need clear definition for other kinds of compatibility (wire,
> client-dependencies, server-dependencies etc.)
> - Not ready for production deployments
>
> GA
>
> - Ready for production
> - All the usual compatibility guarantees apply.
>
> If there is general agreement, I can work towards getting this into our
> documentation.
>
>
>>
>>> 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.
>>>
>>> While we're still in alpha for 3.0.0, there's no need for a separate
>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>
>
> Branching at beta time seems reasonable.
>
> Overall, are there any incompatible changes on trunk that we wouldn't be
> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
> those bits ever?
>
>
>>
>> Best,
>> Andrew
>>
>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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
Ping me if you'd like edit/comment privs, or send comments to this thread.
I'm eager to close on this so we can keeping pushing on the 2.8.0 and
3.0.0-alpha1 releases. I'd like to post this content somewhere official
early next week, so if you have additional feedback, please keep it coming.
Best,
Andrew
On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> 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
>>> misunderstanding the risky here.
>>>
>>
>> These are the definitions of "alpha" and "beta" used leading up to the
>> 2.2 GA release, so it's not something new. These are also the normal
>> industry definitions. Alpha means no API compatibility guarantees, early
>> software. Beta means API compatible, but still some bugs.
>>
>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>> releases post-2.2 GA. The thinking was that everything after would be
>> compatible and thus (at the least) never alpha. I think this is why the
>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>> we could have just called 2.7.0 "beta".
>>
>> I think this would be good to have in our compat guidelines or somewhere.
>> Happy to work with Karthik/Vinod/others on this.
>>
>
> I am not sure if we formally defined the terms "alpha" and "beta" for
> Hadoop 2, but my understanding of them agrees with the general definitions
> on the web.
>
> Alpha:
>
> - Early version for testing - integration with downstream, deployment
> etc.
> - Not feature complete
> - No compatibility guarantees yet
>
> Beta:
>
> - Feature complete
> - API compatibility guaranteed
> - Need clear definition for other kinds of compatibility (wire,
> client-dependencies, server-dependencies etc.)
> - Not ready for production deployments
>
> GA
>
> - Ready for production
> - All the usual compatibility guarantees apply.
>
> If there is general agreement, I can work towards getting this into our
> documentation.
>
>
>>
>>> 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.
>>>
>>> While we're still in alpha for 3.0.0, there's no need for a separate
>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>
>
> Branching at beta time seems reasonable.
>
> Overall, are there any incompatible changes on trunk that we wouldn't be
> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
> those bits ever?
>
>
>>
>> Best,
>> Andrew
>>
>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
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
>> misunderstanding the risky here.
>>
>
> These are the definitions of "alpha" and "beta" used leading up to the 2.2
> GA release, so it's not something new. These are also the normal industry
> definitions. Alpha means no API compatibility guarantees, early software.
> Beta means API compatible, but still some bugs.
>
> If anything, we never defined the terms "alpha" and "beta" for 2.x
> releases post-2.2 GA. The thinking was that everything after would be
> compatible and thus (at the least) never alpha. I think this is why the
> website talks about the 2.7.x line as "stable" or "unstable" instead, but
> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
> we could have just called 2.7.0 "beta".
>
> I think this would be good to have in our compat guidelines or somewhere.
> Happy to work with Karthik/Vinod/others on this.
>
I am not sure if we formally defined the terms "alpha" and "beta" for
Hadoop 2, but my understanding of them agrees with the general definitions
on the web.
Alpha:
- Early version for testing - integration with downstream, deployment
etc.
- Not feature complete
- No compatibility guarantees yet
Beta:
- Feature complete
- API compatibility guaranteed
- Need clear definition for other kinds of compatibility (wire,
client-dependencies, server-dependencies etc.)
- Not ready for production deployments
GA
- Ready for production
- All the usual compatibility guarantees apply.
If there is general agreement, I can work towards getting this into our
documentation.
>
>> 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.
>>
>> While we're still in alpha for 3.0.0, there's no need for a separate
> 4.0.0 version since there's no guarantee of API compatibility. I plan to
> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>
Branching at beta time seems reasonable.
Overall, are there any incompatible changes on trunk that we wouldn't be
comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
those bits ever?
>
> Best,
> Andrew
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
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
>> misunderstanding the risky here.
>>
>
> These are the definitions of "alpha" and "beta" used leading up to the 2.2
> GA release, so it's not something new. These are also the normal industry
> definitions. Alpha means no API compatibility guarantees, early software.
> Beta means API compatible, but still some bugs.
>
> If anything, we never defined the terms "alpha" and "beta" for 2.x
> releases post-2.2 GA. The thinking was that everything after would be
> compatible and thus (at the least) never alpha. I think this is why the
> website talks about the 2.7.x line as "stable" or "unstable" instead, but
> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
> we could have just called 2.7.0 "beta".
>
> I think this would be good to have in our compat guidelines or somewhere.
> Happy to work with Karthik/Vinod/others on this.
>
I am not sure if we formally defined the terms "alpha" and "beta" for
Hadoop 2, but my understanding of them agrees with the general definitions
on the web.
Alpha:
- Early version for testing - integration with downstream, deployment
etc.
- Not feature complete
- No compatibility guarantees yet
Beta:
- Feature complete
- API compatibility guaranteed
- Need clear definition for other kinds of compatibility (wire,
client-dependencies, server-dependencies etc.)
- Not ready for production deployments
GA
- Ready for production
- All the usual compatibility guarantees apply.
If there is general agreement, I can work towards getting this into our
documentation.
>
>> 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.
>>
>> While we're still in alpha for 3.0.0, there's no need for a separate
> 4.0.0 version since there's no guarantee of API compatibility. I plan to
> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>
Branching at beta time seems reasonable.
Overall, are there any incompatible changes on trunk that we wouldn't be
comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
those bits ever?
>
> Best,
> Andrew
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
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
>> misunderstanding the risky here.
>>
>
> These are the definitions of "alpha" and "beta" used leading up to the 2.2
> GA release, so it's not something new. These are also the normal industry
> definitions. Alpha means no API compatibility guarantees, early software.
> Beta means API compatible, but still some bugs.
>
> If anything, we never defined the terms "alpha" and "beta" for 2.x
> releases post-2.2 GA. The thinking was that everything after would be
> compatible and thus (at the least) never alpha. I think this is why the
> website talks about the 2.7.x line as "stable" or "unstable" instead, but
> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
> we could have just called 2.7.0 "beta".
>
> I think this would be good to have in our compat guidelines or somewhere.
> Happy to work with Karthik/Vinod/others on this.
>
I am not sure if we formally defined the terms "alpha" and "beta" for
Hadoop 2, but my understanding of them agrees with the general definitions
on the web.
Alpha:
- Early version for testing - integration with downstream, deployment
etc.
- Not feature complete
- No compatibility guarantees yet
Beta:
- Feature complete
- API compatibility guaranteed
- Need clear definition for other kinds of compatibility (wire,
client-dependencies, server-dependencies etc.)
- Not ready for production deployments
GA
- Ready for production
- All the usual compatibility guarantees apply.
If there is general agreement, I can work towards getting this into our
documentation.
>
>> 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.
>>
>> While we're still in alpha for 3.0.0, there's no need for a separate
> 4.0.0 version since there's no guarantee of API compatibility. I plan to
> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>
Branching at beta time seems reasonable.
Overall, are there any incompatible changes on trunk that we wouldn't be
comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
those bits ever?
>
> Best,
> Andrew
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Karthik Kambatla <ka...@cloudera.com>.
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
>> misunderstanding the risky here.
>>
>
> These are the definitions of "alpha" and "beta" used leading up to the 2.2
> GA release, so it's not something new. These are also the normal industry
> definitions. Alpha means no API compatibility guarantees, early software.
> Beta means API compatible, but still some bugs.
>
> If anything, we never defined the terms "alpha" and "beta" for 2.x
> releases post-2.2 GA. The thinking was that everything after would be
> compatible and thus (at the least) never alpha. I think this is why the
> website talks about the 2.7.x line as "stable" or "unstable" instead, but
> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
> we could have just called 2.7.0 "beta".
>
> I think this would be good to have in our compat guidelines or somewhere.
> Happy to work with Karthik/Vinod/others on this.
>
I am not sure if we formally defined the terms "alpha" and "beta" for
Hadoop 2, but my understanding of them agrees with the general definitions
on the web.
Alpha:
- Early version for testing - integration with downstream, deployment
etc.
- Not feature complete
- No compatibility guarantees yet
Beta:
- Feature complete
- API compatibility guaranteed
- Need clear definition for other kinds of compatibility (wire,
client-dependencies, server-dependencies etc.)
- Not ready for production deployments
GA
- Ready for production
- All the usual compatibility guarantees apply.
If there is general agreement, I can work towards getting this into our
documentation.
>
>> 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.
>>
>> While we're still in alpha for 3.0.0, there's no need for a separate
> 4.0.0 version since there's no guarantee of API compatibility. I plan to
> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>
Branching at beta time seems reasonable.
Overall, are there any incompatible changes on trunk that we wouldn't be
comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
those bits ever?
>
> Best,
> Andrew
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Hi Junping, thanks for sharing your thoughts, inline,
On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 <ju...@apache.org> 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 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).
>
Based on the website, 2.7.0 immediately followed 2.6.0, so that's not quite
accurate. However your point does hold for 2.5.2 -> 2.6.0.
Vinod already described this earlier, where for a while we only had a
single chronological release line. Now though, we have the concurrent 2.6.x
and 2.7.x release lines, which do fix versions independently.
One goal here is a versioning scheme that extends this concurrency to
additional major and minor releases, i.e. 2.8 and 3.0. It doesn't make
sense to have a global ordering of releases, since not all patches belong
in all branches. It also poses additional coordination cost for release
management, particularly since it's hard to predict release timings.
Another goal is a scheme that is easy for users to understand. I believe
the above scheme accurately encodes the versioning system used by most
other enterprise software.
> 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.
>
> These rules seem to require a high degree of coordination when it comes to
release ordering, but one goal is to reduce coordination. For example, the
2.7.0 notes say "Production users should wait for a 2.7.1/2.7.2 release."
We didn't know in advance if 2.7.1 or 2.7.2 would be the stable release. We
also don't know the release ordering of 2.7.4 and 2.8.0.
Given the uncertainty around release timing and stability, it's
advantageous to avoid basing versioning on these two pieces of information.
With these rules, a changes in stability or release ordering means we need
to update JIRA fix versions.
I also didn't quite follow your example, since I assume that 2.8.0 will
*not* be marked stable similar to how 2.7.0 is not stable. If this is true,
does rule 1 take precedence and we would base 3.0.0-alpha1 off of 2.7.4
(the latest stable release)? That seems confusing given the presence of
2.8.0.
Could you elaborate on what you see as the advantages of this scheme from a
user POV? It seems like users now need to be aware of the total ordering
and also stability of releases to know what changelogs to read. And as
described previously, it's not how other enterprise software versioning
works.
> > 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.
>
> We already need to backport to many branches, setting some more fix
versions doesn't change that. Setting more fix versions is also not related
to review bandwidth, particularly in this case since things normally land
in trunk first. It's also not related to the number of concurrent releases,
since release-related effort is not zero-sum.
> 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.
>
These are the definitions of "alpha" and "beta" used leading up to the 2.2
GA release, so it's not something new. These are also the normal industry
definitions. Alpha means no API compatibility guarantees, early software.
Beta means API compatible, but still some bugs.
If anything, we never defined the terms "alpha" and "beta" for 2.x releases
post-2.2 GA. The thinking was that everything after would be compatible and
thus (at the least) never alpha. I think this is why the website talks
about the 2.7.x line as "stable" or "unstable" instead, but since I think
we still guarantee API compatibility between 2.7.0 and 2.7.1, we could have
just called 2.7.0 "beta".
I think this would be good to have in our compat guidelines or somewhere.
Happy to work with Karthik/Vinod/others on this.
> 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.
>
> While we're still in alpha for 3.0.0, there's no need for a separate 4.0.0
version since there's no guarantee of API compatibility. I plan to cut a
branch-3 for the beta period, at which point we'll upgrade trunk to
4.0.0-alpha1. This is something we discussed on another mailing list thread.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Hi Junping, thanks for sharing your thoughts, inline,
On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 <ju...@apache.org> 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 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).
>
Based on the website, 2.7.0 immediately followed 2.6.0, so that's not quite
accurate. However your point does hold for 2.5.2 -> 2.6.0.
Vinod already described this earlier, where for a while we only had a
single chronological release line. Now though, we have the concurrent 2.6.x
and 2.7.x release lines, which do fix versions independently.
One goal here is a versioning scheme that extends this concurrency to
additional major and minor releases, i.e. 2.8 and 3.0. It doesn't make
sense to have a global ordering of releases, since not all patches belong
in all branches. It also poses additional coordination cost for release
management, particularly since it's hard to predict release timings.
Another goal is a scheme that is easy for users to understand. I believe
the above scheme accurately encodes the versioning system used by most
other enterprise software.
> 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.
>
> These rules seem to require a high degree of coordination when it comes to
release ordering, but one goal is to reduce coordination. For example, the
2.7.0 notes say "Production users should wait for a 2.7.1/2.7.2 release."
We didn't know in advance if 2.7.1 or 2.7.2 would be the stable release. We
also don't know the release ordering of 2.7.4 and 2.8.0.
Given the uncertainty around release timing and stability, it's
advantageous to avoid basing versioning on these two pieces of information.
With these rules, a changes in stability or release ordering means we need
to update JIRA fix versions.
I also didn't quite follow your example, since I assume that 2.8.0 will
*not* be marked stable similar to how 2.7.0 is not stable. If this is true,
does rule 1 take precedence and we would base 3.0.0-alpha1 off of 2.7.4
(the latest stable release)? That seems confusing given the presence of
2.8.0.
Could you elaborate on what you see as the advantages of this scheme from a
user POV? It seems like users now need to be aware of the total ordering
and also stability of releases to know what changelogs to read. And as
described previously, it's not how other enterprise software versioning
works.
> > 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.
>
> We already need to backport to many branches, setting some more fix
versions doesn't change that. Setting more fix versions is also not related
to review bandwidth, particularly in this case since things normally land
in trunk first. It's also not related to the number of concurrent releases,
since release-related effort is not zero-sum.
> 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.
>
These are the definitions of "alpha" and "beta" used leading up to the 2.2
GA release, so it's not something new. These are also the normal industry
definitions. Alpha means no API compatibility guarantees, early software.
Beta means API compatible, but still some bugs.
If anything, we never defined the terms "alpha" and "beta" for 2.x releases
post-2.2 GA. The thinking was that everything after would be compatible and
thus (at the least) never alpha. I think this is why the website talks
about the 2.7.x line as "stable" or "unstable" instead, but since I think
we still guarantee API compatibility between 2.7.0 and 2.7.1, we could have
just called 2.7.0 "beta".
I think this would be good to have in our compat guidelines or somewhere.
Happy to work with Karthik/Vinod/others on this.
> 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.
>
> While we're still in alpha for 3.0.0, there's no need for a separate 4.0.0
version since there's no guarantee of API compatibility. I plan to cut a
branch-3 for the beta period, at which point we'll upgrade trunk to
4.0.0-alpha1. This is something we discussed on another mailing list thread.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Hi Junping, thanks for sharing your thoughts, inline,
On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 <ju...@apache.org> 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 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).
>
Based on the website, 2.7.0 immediately followed 2.6.0, so that's not quite
accurate. However your point does hold for 2.5.2 -> 2.6.0.
Vinod already described this earlier, where for a while we only had a
single chronological release line. Now though, we have the concurrent 2.6.x
and 2.7.x release lines, which do fix versions independently.
One goal here is a versioning scheme that extends this concurrency to
additional major and minor releases, i.e. 2.8 and 3.0. It doesn't make
sense to have a global ordering of releases, since not all patches belong
in all branches. It also poses additional coordination cost for release
management, particularly since it's hard to predict release timings.
Another goal is a scheme that is easy for users to understand. I believe
the above scheme accurately encodes the versioning system used by most
other enterprise software.
> 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.
>
> These rules seem to require a high degree of coordination when it comes to
release ordering, but one goal is to reduce coordination. For example, the
2.7.0 notes say "Production users should wait for a 2.7.1/2.7.2 release."
We didn't know in advance if 2.7.1 or 2.7.2 would be the stable release. We
also don't know the release ordering of 2.7.4 and 2.8.0.
Given the uncertainty around release timing and stability, it's
advantageous to avoid basing versioning on these two pieces of information.
With these rules, a changes in stability or release ordering means we need
to update JIRA fix versions.
I also didn't quite follow your example, since I assume that 2.8.0 will
*not* be marked stable similar to how 2.7.0 is not stable. If this is true,
does rule 1 take precedence and we would base 3.0.0-alpha1 off of 2.7.4
(the latest stable release)? That seems confusing given the presence of
2.8.0.
Could you elaborate on what you see as the advantages of this scheme from a
user POV? It seems like users now need to be aware of the total ordering
and also stability of releases to know what changelogs to read. And as
described previously, it's not how other enterprise software versioning
works.
> > 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.
>
> We already need to backport to many branches, setting some more fix
versions doesn't change that. Setting more fix versions is also not related
to review bandwidth, particularly in this case since things normally land
in trunk first. It's also not related to the number of concurrent releases,
since release-related effort is not zero-sum.
> 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.
>
These are the definitions of "alpha" and "beta" used leading up to the 2.2
GA release, so it's not something new. These are also the normal industry
definitions. Alpha means no API compatibility guarantees, early software.
Beta means API compatible, but still some bugs.
If anything, we never defined the terms "alpha" and "beta" for 2.x releases
post-2.2 GA. The thinking was that everything after would be compatible and
thus (at the least) never alpha. I think this is why the website talks
about the 2.7.x line as "stable" or "unstable" instead, but since I think
we still guarantee API compatibility between 2.7.0 and 2.7.1, we could have
just called 2.7.0 "beta".
I think this would be good to have in our compat guidelines or somewhere.
Happy to work with Karthik/Vinod/others on this.
> 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.
>
> While we're still in alpha for 3.0.0, there's no need for a separate 4.0.0
version since there's no guarantee of API compatibility. I plan to cut a
branch-3 for the beta period, at which point we'll upgrade trunk to
4.0.0-alpha1. This is something we discussed on another mailing list thread.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Hi Junping, thanks for sharing your thoughts, inline,
On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 <ju...@apache.org> 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 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).
>
Based on the website, 2.7.0 immediately followed 2.6.0, so that's not quite
accurate. However your point does hold for 2.5.2 -> 2.6.0.
Vinod already described this earlier, where for a while we only had a
single chronological release line. Now though, we have the concurrent 2.6.x
and 2.7.x release lines, which do fix versions independently.
One goal here is a versioning scheme that extends this concurrency to
additional major and minor releases, i.e. 2.8 and 3.0. It doesn't make
sense to have a global ordering of releases, since not all patches belong
in all branches. It also poses additional coordination cost for release
management, particularly since it's hard to predict release timings.
Another goal is a scheme that is easy for users to understand. I believe
the above scheme accurately encodes the versioning system used by most
other enterprise software.
> 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.
>
> These rules seem to require a high degree of coordination when it comes to
release ordering, but one goal is to reduce coordination. For example, the
2.7.0 notes say "Production users should wait for a 2.7.1/2.7.2 release."
We didn't know in advance if 2.7.1 or 2.7.2 would be the stable release. We
also don't know the release ordering of 2.7.4 and 2.8.0.
Given the uncertainty around release timing and stability, it's
advantageous to avoid basing versioning on these two pieces of information.
With these rules, a changes in stability or release ordering means we need
to update JIRA fix versions.
I also didn't quite follow your example, since I assume that 2.8.0 will
*not* be marked stable similar to how 2.7.0 is not stable. If this is true,
does rule 1 take precedence and we would base 3.0.0-alpha1 off of 2.7.4
(the latest stable release)? That seems confusing given the presence of
2.8.0.
Could you elaborate on what you see as the advantages of this scheme from a
user POV? It seems like users now need to be aware of the total ordering
and also stability of releases to know what changelogs to read. And as
described previously, it's not how other enterprise software versioning
works.
> > 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.
>
> We already need to backport to many branches, setting some more fix
versions doesn't change that. Setting more fix versions is also not related
to review bandwidth, particularly in this case since things normally land
in trunk first. It's also not related to the number of concurrent releases,
since release-related effort is not zero-sum.
> 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.
>
These are the definitions of "alpha" and "beta" used leading up to the 2.2
GA release, so it's not something new. These are also the normal industry
definitions. Alpha means no API compatibility guarantees, early software.
Beta means API compatible, but still some bugs.
If anything, we never defined the terms "alpha" and "beta" for 2.x releases
post-2.2 GA. The thinking was that everything after would be compatible and
thus (at the least) never alpha. I think this is why the website talks
about the 2.7.x line as "stable" or "unstable" instead, but since I think
we still guarantee API compatibility between 2.7.0 and 2.7.1, we could have
just called 2.7.0 "beta".
I think this would be good to have in our compat guidelines or somewhere.
Happy to work with Karthik/Vinod/others on this.
> 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.
>
> While we're still in alpha for 3.0.0, there's no need for a separate 4.0.0
version since there's no guarantee of API compatibility. I plan to cut a
branch-3 for the beta period, at which point we'll upgrade trunk to
4.0.0-alpha1. This is something we discussed on another mailing list thread.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by 俊平堵 <ju...@apache.org>.
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
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by 俊平堵 <ju...@apache.org>.
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
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by 俊平堵 <ju...@apache.org>.
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
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
>
> 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?
>
>
Yea. It means the if you're coming from 2.7, you'd read the 3.0.0-alphas,
3.0.0-betas, and finally the 3.0.0 GA notes.
The website notes will aggregate all the alpha and beta changes leading up
to 3.0.0 GA, so is likely where users will turn to first.
>
>> 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?
>
>
Yea, I have a script and some JIRA queries that can help with this. I'll
also plan to compare with git log contents for extra verification.
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
>
> 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?
>
>
Yea. It means the if you're coming from 2.7, you'd read the 3.0.0-alphas,
3.0.0-betas, and finally the 3.0.0 GA notes.
The website notes will aggregate all the alpha and beta changes leading up
to 3.0.0 GA, so is likely where users will turn to first.
>
>> 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?
>
>
Yea, I have a script and some JIRA queries that can help with this. I'll
also plan to compare with git log contents for extra verification.
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
>
> 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?
>
>
Yea. It means the if you're coming from 2.7, you'd read the 3.0.0-alphas,
3.0.0-betas, and finally the 3.0.0 GA notes.
The website notes will aggregate all the alpha and beta changes leading up
to 3.0.0 GA, so is likely where users will turn to first.
>
>> 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?
>
>
Yea, I have a script and some JIRA queries that can help with this. I'll
also plan to compare with git log contents for extra verification.
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by 俊平堵 <ju...@apache.org>.
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
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by 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
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Akira Ajisaka <aj...@oss.nttdata.co.jp>.
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: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Akira Ajisaka <aj...@oss.nttdata.co.jp>.
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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by 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
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by 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
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Akira Ajisaka <aj...@oss.nttdata.co.jp>.
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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Konstantin Shvachko <sh...@gmail.com>.
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.
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.
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.
Thanks,
--Konstantin
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Konstantin Shvachko <sh...@gmail.com>.
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.
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.
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.
Thanks,
--Konstantin
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Akira Ajisaka <aj...@oss.nttdata.co.jp>.
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
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Konstantin Shvachko <sh...@gmail.com>.
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.
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.
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.
Thanks,
--Konstantin
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by 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
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
> 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 maintenance
branches, it helps us to understand which branches include fix a
problem of my cluster.
> I think this problem is also pretty rare in practice, since users normally upgrade to the highest maintenance release within a major/minor.
If there will be lots maintenance branches in parallel(2.6.x, 2.7.x,
2.8.x, 2.9.x, 3.0.x), we can hit this problem more easily - if a user
uses plan to upgrade 2.7.3 cluster to 2.8.3 or 2.9.1 or 3.0.1, which
version should the user choose? This is my concern.
However, as you mentioned, we decide to reduce the number of branches
we keep maintenance, we don't need to do that.
Best,
- Tsuyoshi
On Wed, Jul 27, 2016 at 3:40 PM, Andrew Wang <an...@cloudera.com> wrote:
> 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 still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later 2.7.c
> release (found easily since a.b.c releases are ordered), and when jumping to
> a new minor or major version, any version released chronologically after
> 2.7.3. This means you need to check the website, but given that this is the
> way most enterprise software is versioned, I think it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>>
>> > 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 release can be
>> delayed after the release pass. Does it make sense to you?
>>
>> > Even if we have the branch-cut date in the version string, devs still
>> > need to be aware of other branches and backport appropriately.
>>
>> Yes, you're right. The good point of including date is that we can declare
>> which version includes the latest changes. It helps users, not devs
>> basically, to decide which version users will use: e.g. if 2.8.1-20160801 is
>> released after 2.9.0-20160701 and a user uses 2.7.3-20160701, she can update
>> their cluster 2.8.1, which include bug fixes against 2.7.3. Please let me
>> know if I have some missing points.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>>>
>>> Thanks for replies Akira and Tsuyoshi, inline:
>>>
>>>> Akira: 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?
>>>
>>>
>>> Yes, correct.
>>>
>>>>
>>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>>
>>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>>> to maintainance branches after the date, users can find that which
>>>> version
>>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>>
>>>> Cons:-( A bit redundant.
>>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>>> our releases, when ordered chronologically, to incorporate all the known
>>> relevant bug fixes. Even if we have the branch-cut date in the version
>>> string, devs still need to be aware of other branches and backport
>>> appropriately.
>>>
>>> Given that branch cuts and releases might not happen in the same order
>>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>>> for users. I bet many would assume it's the release date, like how Ubuntu
>>> releases are numbered.
>>>
>>> Best,
>>> Andrew
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
> 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 maintenance
branches, it helps us to understand which branches include fix a
problem of my cluster.
> I think this problem is also pretty rare in practice, since users normally upgrade to the highest maintenance release within a major/minor.
If there will be lots maintenance branches in parallel(2.6.x, 2.7.x,
2.8.x, 2.9.x, 3.0.x), we can hit this problem more easily - if a user
uses plan to upgrade 2.7.3 cluster to 2.8.3 or 2.9.1 or 3.0.1, which
version should the user choose? This is my concern.
However, as you mentioned, we decide to reduce the number of branches
we keep maintenance, we don't need to do that.
Best,
- Tsuyoshi
On Wed, Jul 27, 2016 at 3:40 PM, Andrew Wang <an...@cloudera.com> wrote:
> 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 still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later 2.7.c
> release (found easily since a.b.c releases are ordered), and when jumping to
> a new minor or major version, any version released chronologically after
> 2.7.3. This means you need to check the website, but given that this is the
> way most enterprise software is versioned, I think it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>>
>> > 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 release can be
>> delayed after the release pass. Does it make sense to you?
>>
>> > Even if we have the branch-cut date in the version string, devs still
>> > need to be aware of other branches and backport appropriately.
>>
>> Yes, you're right. The good point of including date is that we can declare
>> which version includes the latest changes. It helps users, not devs
>> basically, to decide which version users will use: e.g. if 2.8.1-20160801 is
>> released after 2.9.0-20160701 and a user uses 2.7.3-20160701, she can update
>> their cluster 2.8.1, which include bug fixes against 2.7.3. Please let me
>> know if I have some missing points.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>>>
>>> Thanks for replies Akira and Tsuyoshi, inline:
>>>
>>>> Akira: 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?
>>>
>>>
>>> Yes, correct.
>>>
>>>>
>>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>>
>>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>>> to maintainance branches after the date, users can find that which
>>>> version
>>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>>
>>>> Cons:-( A bit redundant.
>>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>>> our releases, when ordered chronologically, to incorporate all the known
>>> relevant bug fixes. Even if we have the branch-cut date in the version
>>> string, devs still need to be aware of other branches and backport
>>> appropriately.
>>>
>>> Given that branch cuts and releases might not happen in the same order
>>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>>> for users. I bet many would assume it's the release date, like how Ubuntu
>>> releases are numbered.
>>>
>>> Best,
>>> Andrew
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Wangda Tan <wh...@gmail.com>.
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 note) should look like?*
Not sure if this is discussed before. Previously we put the *next* release
version of earliest branch to CHANGES.txt. However, this could be confusing
and need a lot of manual works.
For example, we have two parallel release branches: branch-2.6.5 and
branch-2.7.4. When we need to backport a commit X in branch-2.7.4 to
branch-2.6.5, we will update CHANGES.txt in branch-2.7.4 to say this commit
X is included by Hadoop-2.6.5.
However, if we release Hadoop-2.7.4 before Hadoop-2.6.5, user will find the
Hadoop-2.6.5 is not released yet.
To me, we should put the fix version in CHANGES.txt to the released Hadoop
from the earliest branch, in the above example, Hadoop-2.7.4 should be the
fix version of commit X in release note of Hadoop-2.7.4.
Instead, I suggest to add a suffix ("released") to the fix version after
release is done. So the release note generator can do query easier, and
other user of JIRA can benefit from this to understand which releases
include a given JIRA.
*2) Do we need to update historical JIRAs?*
It's better to make a consistent rule for active release branches (to me
they're branch-2.6 and up). So it will be better to update fix version for
all resolved JIRAs in release branches.
Thoughts?
Wangda
On Tue, Jul 26, 2016 at 11:40 PM, Andrew Wang <an...@cloudera.com>
wrote:
> 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 still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later
> 2.7.c release (found easily since a.b.c releases are ordered), and when
> jumping to a new minor or major version, any version released
> chronologically after 2.7.3. This means you need to check the website, but
> given that this is the way most enterprise software is versioned, I think
> it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>
> > > 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 release can
> > be delayed after the release pass. Does it make sense to you?
> >
> > > Even if we have the branch-cut date in the version string, devs still
> > need to be aware of other branches and backport appropriately.
> >
> > Yes, you're right. The good point of including date is that we can
> declare
> > which version includes the latest changes. It helps users, not devs
> > basically, to decide which version users will use: e.g. if
> > 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> > 2.7.3-20160701, she can update their cluster 2.8.1, which include bug
> fixes
> > against 2.7.3. Please let me know if I have some missing points.
> >
> > Thanks,
> > - Tsuyoshi
> >
> > On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> Thanks for replies Akira and Tsuyoshi, inline:
> >>
> >> Akira: 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?
> >>
> >>
> >> Yes, correct.
> >>
> >>
> >>> Tsuyoshi: My suggestion is adding the date when branch cut is done:
> like
> >>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
> >>>
> >>> Pros:-) It's totally ordered. If we have a policy such as backporting
> >>> to maintainance branches after the date, users can find that which
> >>> version
> >>> is cutting edge. In the example of above, 2.8.0-20160730 can include
> bug
> >>> fixes which is not included in 3.0.0-alpha1-20160724.
> >>>
> >>> Cons:-( A bit redundant.
> >>>
> >>> Could you elaborate on the problem this scheme addresses? We always
> want
> >> our releases, when ordered chronologically, to incorporate all the known
> >> relevant bug fixes. Even if we have the branch-cut date in the version
> >> string, devs still need to be aware of other branches and backport
> >> appropriately.
> >>
> >> Given that branch cuts and releases might not happen in the same order
> >> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be
> confusing
> >> for users. I bet many would assume it's the release date, like how
> Ubuntu
> >> releases are numbered.
> >>
> >> Best,
> >> Andrew
> >>
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Wangda Tan <wh...@gmail.com>.
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 note) should look like?*
Not sure if this is discussed before. Previously we put the *next* release
version of earliest branch to CHANGES.txt. However, this could be confusing
and need a lot of manual works.
For example, we have two parallel release branches: branch-2.6.5 and
branch-2.7.4. When we need to backport a commit X in branch-2.7.4 to
branch-2.6.5, we will update CHANGES.txt in branch-2.7.4 to say this commit
X is included by Hadoop-2.6.5.
However, if we release Hadoop-2.7.4 before Hadoop-2.6.5, user will find the
Hadoop-2.6.5 is not released yet.
To me, we should put the fix version in CHANGES.txt to the released Hadoop
from the earliest branch, in the above example, Hadoop-2.7.4 should be the
fix version of commit X in release note of Hadoop-2.7.4.
Instead, I suggest to add a suffix ("released") to the fix version after
release is done. So the release note generator can do query easier, and
other user of JIRA can benefit from this to understand which releases
include a given JIRA.
*2) Do we need to update historical JIRAs?*
It's better to make a consistent rule for active release branches (to me
they're branch-2.6 and up). So it will be better to update fix version for
all resolved JIRAs in release branches.
Thoughts?
Wangda
On Tue, Jul 26, 2016 at 11:40 PM, Andrew Wang <an...@cloudera.com>
wrote:
> 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 still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later
> 2.7.c release (found easily since a.b.c releases are ordered), and when
> jumping to a new minor or major version, any version released
> chronologically after 2.7.3. This means you need to check the website, but
> given that this is the way most enterprise software is versioned, I think
> it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>
> > > 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 release can
> > be delayed after the release pass. Does it make sense to you?
> >
> > > Even if we have the branch-cut date in the version string, devs still
> > need to be aware of other branches and backport appropriately.
> >
> > Yes, you're right. The good point of including date is that we can
> declare
> > which version includes the latest changes. It helps users, not devs
> > basically, to decide which version users will use: e.g. if
> > 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> > 2.7.3-20160701, she can update their cluster 2.8.1, which include bug
> fixes
> > against 2.7.3. Please let me know if I have some missing points.
> >
> > Thanks,
> > - Tsuyoshi
> >
> > On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> Thanks for replies Akira and Tsuyoshi, inline:
> >>
> >> Akira: 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?
> >>
> >>
> >> Yes, correct.
> >>
> >>
> >>> Tsuyoshi: My suggestion is adding the date when branch cut is done:
> like
> >>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
> >>>
> >>> Pros:-) It's totally ordered. If we have a policy such as backporting
> >>> to maintainance branches after the date, users can find that which
> >>> version
> >>> is cutting edge. In the example of above, 2.8.0-20160730 can include
> bug
> >>> fixes which is not included in 3.0.0-alpha1-20160724.
> >>>
> >>> Cons:-( A bit redundant.
> >>>
> >>> Could you elaborate on the problem this scheme addresses? We always
> want
> >> our releases, when ordered chronologically, to incorporate all the known
> >> relevant bug fixes. Even if we have the branch-cut date in the version
> >> string, devs still need to be aware of other branches and backport
> >> appropriately.
> >>
> >> Given that branch cuts and releases might not happen in the same order
> >> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be
> confusing
> >> for users. I bet many would assume it's the release date, like how
> Ubuntu
> >> releases are numbered.
> >>
> >> Best,
> >> Andrew
> >>
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
> 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 maintenance
branches, it helps us to understand which branches include fix a
problem of my cluster.
> I think this problem is also pretty rare in practice, since users normally upgrade to the highest maintenance release within a major/minor.
If there will be lots maintenance branches in parallel(2.6.x, 2.7.x,
2.8.x, 2.9.x, 3.0.x), we can hit this problem more easily - if a user
uses plan to upgrade 2.7.3 cluster to 2.8.3 or 2.9.1 or 3.0.1, which
version should the user choose? This is my concern.
However, as you mentioned, we decide to reduce the number of branches
we keep maintenance, we don't need to do that.
Best,
- Tsuyoshi
On Wed, Jul 27, 2016 at 3:40 PM, Andrew Wang <an...@cloudera.com> wrote:
> 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 still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later 2.7.c
> release (found easily since a.b.c releases are ordered), and when jumping to
> a new minor or major version, any version released chronologically after
> 2.7.3. This means you need to check the website, but given that this is the
> way most enterprise software is versioned, I think it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>>
>> > 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 release can be
>> delayed after the release pass. Does it make sense to you?
>>
>> > Even if we have the branch-cut date in the version string, devs still
>> > need to be aware of other branches and backport appropriately.
>>
>> Yes, you're right. The good point of including date is that we can declare
>> which version includes the latest changes. It helps users, not devs
>> basically, to decide which version users will use: e.g. if 2.8.1-20160801 is
>> released after 2.9.0-20160701 and a user uses 2.7.3-20160701, she can update
>> their cluster 2.8.1, which include bug fixes against 2.7.3. Please let me
>> know if I have some missing points.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>>>
>>> Thanks for replies Akira and Tsuyoshi, inline:
>>>
>>>> Akira: 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?
>>>
>>>
>>> Yes, correct.
>>>
>>>>
>>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>>
>>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>>> to maintainance branches after the date, users can find that which
>>>> version
>>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>>
>>>> Cons:-( A bit redundant.
>>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>>> our releases, when ordered chronologically, to incorporate all the known
>>> relevant bug fixes. Even if we have the branch-cut date in the version
>>> string, devs still need to be aware of other branches and backport
>>> appropriately.
>>>
>>> Given that branch cuts and releases might not happen in the same order
>>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>>> for users. I bet many would assume it's the release date, like how Ubuntu
>>> releases are numbered.
>>>
>>> Best,
>>> Andrew
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Wangda Tan <wh...@gmail.com>.
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 note) should look like?*
Not sure if this is discussed before. Previously we put the *next* release
version of earliest branch to CHANGES.txt. However, this could be confusing
and need a lot of manual works.
For example, we have two parallel release branches: branch-2.6.5 and
branch-2.7.4. When we need to backport a commit X in branch-2.7.4 to
branch-2.6.5, we will update CHANGES.txt in branch-2.7.4 to say this commit
X is included by Hadoop-2.6.5.
However, if we release Hadoop-2.7.4 before Hadoop-2.6.5, user will find the
Hadoop-2.6.5 is not released yet.
To me, we should put the fix version in CHANGES.txt to the released Hadoop
from the earliest branch, in the above example, Hadoop-2.7.4 should be the
fix version of commit X in release note of Hadoop-2.7.4.
Instead, I suggest to add a suffix ("released") to the fix version after
release is done. So the release note generator can do query easier, and
other user of JIRA can benefit from this to understand which releases
include a given JIRA.
*2) Do we need to update historical JIRAs?*
It's better to make a consistent rule for active release branches (to me
they're branch-2.6 and up). So it will be better to update fix version for
all resolved JIRAs in release branches.
Thoughts?
Wangda
On Tue, Jul 26, 2016 at 11:40 PM, Andrew Wang <an...@cloudera.com>
wrote:
> 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 still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later
> 2.7.c release (found easily since a.b.c releases are ordered), and when
> jumping to a new minor or major version, any version released
> chronologically after 2.7.3. This means you need to check the website, but
> given that this is the way most enterprise software is versioned, I think
> it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>
> > > 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 release can
> > be delayed after the release pass. Does it make sense to you?
> >
> > > Even if we have the branch-cut date in the version string, devs still
> > need to be aware of other branches and backport appropriately.
> >
> > Yes, you're right. The good point of including date is that we can
> declare
> > which version includes the latest changes. It helps users, not devs
> > basically, to decide which version users will use: e.g. if
> > 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> > 2.7.3-20160701, she can update their cluster 2.8.1, which include bug
> fixes
> > against 2.7.3. Please let me know if I have some missing points.
> >
> > Thanks,
> > - Tsuyoshi
> >
> > On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> Thanks for replies Akira and Tsuyoshi, inline:
> >>
> >> Akira: 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?
> >>
> >>
> >> Yes, correct.
> >>
> >>
> >>> Tsuyoshi: My suggestion is adding the date when branch cut is done:
> like
> >>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
> >>>
> >>> Pros:-) It's totally ordered. If we have a policy such as backporting
> >>> to maintainance branches after the date, users can find that which
> >>> version
> >>> is cutting edge. In the example of above, 2.8.0-20160730 can include
> bug
> >>> fixes which is not included in 3.0.0-alpha1-20160724.
> >>>
> >>> Cons:-( A bit redundant.
> >>>
> >>> Could you elaborate on the problem this scheme addresses? We always
> want
> >> our releases, when ordered chronologically, to incorporate all the known
> >> relevant bug fixes. Even if we have the branch-cut date in the version
> >> string, devs still need to be aware of other branches and backport
> >> appropriately.
> >>
> >> Given that branch cuts and releases might not happen in the same order
> >> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be
> confusing
> >> for users. I bet many would assume it's the release date, like how
> Ubuntu
> >> releases are numbered.
> >>
> >> Best,
> >> Andrew
> >>
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Wangda Tan <wh...@gmail.com>.
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 note) should look like?*
Not sure if this is discussed before. Previously we put the *next* release
version of earliest branch to CHANGES.txt. However, this could be confusing
and need a lot of manual works.
For example, we have two parallel release branches: branch-2.6.5 and
branch-2.7.4. When we need to backport a commit X in branch-2.7.4 to
branch-2.6.5, we will update CHANGES.txt in branch-2.7.4 to say this commit
X is included by Hadoop-2.6.5.
However, if we release Hadoop-2.7.4 before Hadoop-2.6.5, user will find the
Hadoop-2.6.5 is not released yet.
To me, we should put the fix version in CHANGES.txt to the released Hadoop
from the earliest branch, in the above example, Hadoop-2.7.4 should be the
fix version of commit X in release note of Hadoop-2.7.4.
Instead, I suggest to add a suffix ("released") to the fix version after
release is done. So the release note generator can do query easier, and
other user of JIRA can benefit from this to understand which releases
include a given JIRA.
*2) Do we need to update historical JIRAs?*
It's better to make a consistent rule for active release branches (to me
they're branch-2.6 and up). So it will be better to update fix version for
all resolved JIRAs in release branches.
Thoughts?
Wangda
On Tue, Jul 26, 2016 at 11:40 PM, Andrew Wang <an...@cloudera.com>
wrote:
> 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 still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later
> 2.7.c release (found easily since a.b.c releases are ordered), and when
> jumping to a new minor or major version, any version released
> chronologically after 2.7.3. This means you need to check the website, but
> given that this is the way most enterprise software is versioned, I think
> it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>
> > > 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 release can
> > be delayed after the release pass. Does it make sense to you?
> >
> > > Even if we have the branch-cut date in the version string, devs still
> > need to be aware of other branches and backport appropriately.
> >
> > Yes, you're right. The good point of including date is that we can
> declare
> > which version includes the latest changes. It helps users, not devs
> > basically, to decide which version users will use: e.g. if
> > 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> > 2.7.3-20160701, she can update their cluster 2.8.1, which include bug
> fixes
> > against 2.7.3. Please let me know if I have some missing points.
> >
> > Thanks,
> > - Tsuyoshi
> >
> > On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> Thanks for replies Akira and Tsuyoshi, inline:
> >>
> >> Akira: 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?
> >>
> >>
> >> Yes, correct.
> >>
> >>
> >>> Tsuyoshi: My suggestion is adding the date when branch cut is done:
> like
> >>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
> >>>
> >>> Pros:-) It's totally ordered. If we have a policy such as backporting
> >>> to maintainance branches after the date, users can find that which
> >>> version
> >>> is cutting edge. In the example of above, 2.8.0-20160730 can include
> bug
> >>> fixes which is not included in 3.0.0-alpha1-20160724.
> >>>
> >>> Cons:-( A bit redundant.
> >>>
> >>> Could you elaborate on the problem this scheme addresses? We always
> want
> >> our releases, when ordered chronologically, to incorporate all the known
> >> relevant bug fixes. Even if we have the branch-cut date in the version
> >> string, devs still need to be aware of other branches and backport
> >> appropriately.
> >>
> >> Given that branch cuts and releases might not happen in the same order
> >> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be
> confusing
> >> for users. I bet many would assume it's the release date, like how
> Ubuntu
> >> releases are numbered.
> >>
> >> Best,
> >> Andrew
> >>
> >
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
> 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 maintenance
branches, it helps us to understand which branches include fix a
problem of my cluster.
> I think this problem is also pretty rare in practice, since users normally upgrade to the highest maintenance release within a major/minor.
If there will be lots maintenance branches in parallel(2.6.x, 2.7.x,
2.8.x, 2.9.x, 3.0.x), we can hit this problem more easily - if a user
uses plan to upgrade 2.7.3 cluster to 2.8.3 or 2.9.1 or 3.0.1, which
version should the user choose? This is my concern.
However, as you mentioned, we decide to reduce the number of branches
we keep maintenance, we don't need to do that.
Best,
- Tsuyoshi
On Wed, Jul 27, 2016 at 3:40 PM, Andrew Wang <an...@cloudera.com> wrote:
> 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 still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later 2.7.c
> release (found easily since a.b.c releases are ordered), and when jumping to
> a new minor or major version, any version released chronologically after
> 2.7.3. This means you need to check the website, but given that this is the
> way most enterprise software is versioned, I think it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>>
>> > 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 release can be
>> delayed after the release pass. Does it make sense to you?
>>
>> > Even if we have the branch-cut date in the version string, devs still
>> > need to be aware of other branches and backport appropriately.
>>
>> Yes, you're right. The good point of including date is that we can declare
>> which version includes the latest changes. It helps users, not devs
>> basically, to decide which version users will use: e.g. if 2.8.1-20160801 is
>> released after 2.9.0-20160701 and a user uses 2.7.3-20160701, she can update
>> their cluster 2.8.1, which include bug fixes against 2.7.3. Please let me
>> know if I have some missing points.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>>>
>>> Thanks for replies Akira and Tsuyoshi, inline:
>>>
>>>> Akira: 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?
>>>
>>>
>>> Yes, correct.
>>>
>>>>
>>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>>
>>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>>> to maintainance branches after the date, users can find that which
>>>> version
>>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>>
>>>> Cons:-( A bit redundant.
>>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>>> our releases, when ordered chronologically, to incorporate all the known
>>> relevant bug fixes. Even if we have the branch-cut date in the version
>>> string, devs still need to be aware of other branches and backport
>>> appropriately.
>>>
>>> Given that branch cuts and releases might not happen in the same order
>>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>>> for users. I bet many would assume it's the release date, like how Ubuntu
>>> releases are numbered.
>>>
>>> Best,
>>> Andrew
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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 still totally ordered.
For the user in this scenario, she can upgrade from 2.7.3 to any later
2.7.c release (found easily since a.b.c releases are ordered), and when
jumping to a new minor or major version, any version released
chronologically after 2.7.3. This means you need to check the website, but
given that this is the way most enterprise software is versioned, I think
it'll be okay by users.
I think this problem is also pretty rare in practice, since users normally
upgrade to the highest maintenance release within a major/minor. Thus
they'll only hit this if their upgrade cycle is faster than it takes for a
change released in e.g. 2.6.x to then also be released in a 2.7.x.
Best,
Andrew
On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
> > 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 release can
> be delayed after the release pass. Does it make sense to you?
>
> > Even if we have the branch-cut date in the version string, devs still
> need to be aware of other branches and backport appropriately.
>
> Yes, you're right. The good point of including date is that we can declare
> which version includes the latest changes. It helps users, not devs
> basically, to decide which version users will use: e.g. if
> 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> 2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
> against 2.7.3. Please let me know if I have some missing points.
>
> Thanks,
> - Tsuyoshi
>
> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>
>> Thanks for replies Akira and Tsuyoshi, inline:
>>
>> Akira: 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?
>>
>>
>> Yes, correct.
>>
>>
>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>
>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>> to maintainance branches after the date, users can find that which
>>> version
>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>
>>> Cons:-( A bit redundant.
>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>> our releases, when ordered chronologically, to incorporate all the known
>> relevant bug fixes. Even if we have the branch-cut date in the version
>> string, devs still need to be aware of other branches and backport
>> appropriately.
>>
>> Given that branch cuts and releases might not happen in the same order
>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>> for users. I bet many would assume it's the release date, like how Ubuntu
>> releases are numbered.
>>
>> Best,
>> Andrew
>>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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 still totally ordered.
For the user in this scenario, she can upgrade from 2.7.3 to any later
2.7.c release (found easily since a.b.c releases are ordered), and when
jumping to a new minor or major version, any version released
chronologically after 2.7.3. This means you need to check the website, but
given that this is the way most enterprise software is versioned, I think
it'll be okay by users.
I think this problem is also pretty rare in practice, since users normally
upgrade to the highest maintenance release within a major/minor. Thus
they'll only hit this if their upgrade cycle is faster than it takes for a
change released in e.g. 2.6.x to then also be released in a 2.7.x.
Best,
Andrew
On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
> > 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 release can
> be delayed after the release pass. Does it make sense to you?
>
> > Even if we have the branch-cut date in the version string, devs still
> need to be aware of other branches and backport appropriately.
>
> Yes, you're right. The good point of including date is that we can declare
> which version includes the latest changes. It helps users, not devs
> basically, to decide which version users will use: e.g. if
> 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> 2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
> against 2.7.3. Please let me know if I have some missing points.
>
> Thanks,
> - Tsuyoshi
>
> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>
>> Thanks for replies Akira and Tsuyoshi, inline:
>>
>> Akira: 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?
>>
>>
>> Yes, correct.
>>
>>
>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>
>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>> to maintainance branches after the date, users can find that which
>>> version
>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>
>>> Cons:-( A bit redundant.
>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>> our releases, when ordered chronologically, to incorporate all the known
>> relevant bug fixes. Even if we have the branch-cut date in the version
>> string, devs still need to be aware of other branches and backport
>> appropriately.
>>
>> Given that branch cuts and releases might not happen in the same order
>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>> for users. I bet many would assume it's the release date, like how Ubuntu
>> releases are numbered.
>>
>> Best,
>> Andrew
>>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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 still totally ordered.
For the user in this scenario, she can upgrade from 2.7.3 to any later
2.7.c release (found easily since a.b.c releases are ordered), and when
jumping to a new minor or major version, any version released
chronologically after 2.7.3. This means you need to check the website, but
given that this is the way most enterprise software is versioned, I think
it'll be okay by users.
I think this problem is also pretty rare in practice, since users normally
upgrade to the highest maintenance release within a major/minor. Thus
they'll only hit this if their upgrade cycle is faster than it takes for a
change released in e.g. 2.6.x to then also be released in a 2.7.x.
Best,
Andrew
On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
> > 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 release can
> be delayed after the release pass. Does it make sense to you?
>
> > Even if we have the branch-cut date in the version string, devs still
> need to be aware of other branches and backport appropriately.
>
> Yes, you're right. The good point of including date is that we can declare
> which version includes the latest changes. It helps users, not devs
> basically, to decide which version users will use: e.g. if
> 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> 2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
> against 2.7.3. Please let me know if I have some missing points.
>
> Thanks,
> - Tsuyoshi
>
> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>
>> Thanks for replies Akira and Tsuyoshi, inline:
>>
>> Akira: 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?
>>
>>
>> Yes, correct.
>>
>>
>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>
>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>> to maintainance branches after the date, users can find that which
>>> version
>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>
>>> Cons:-( A bit redundant.
>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>> our releases, when ordered chronologically, to incorporate all the known
>> relevant bug fixes. Even if we have the branch-cut date in the version
>> string, devs still need to be aware of other branches and backport
>> appropriately.
>>
>> Given that branch cuts and releases might not happen in the same order
>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>> for users. I bet many would assume it's the release date, like how Ubuntu
>> releases are numbered.
>>
>> Best,
>> Andrew
>>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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 still totally ordered.
For the user in this scenario, she can upgrade from 2.7.3 to any later
2.7.c release (found easily since a.b.c releases are ordered), and when
jumping to a new minor or major version, any version released
chronologically after 2.7.3. This means you need to check the website, but
given that this is the way most enterprise software is versioned, I think
it'll be okay by users.
I think this problem is also pretty rare in practice, since users normally
upgrade to the highest maintenance release within a major/minor. Thus
they'll only hit this if their upgrade cycle is faster than it takes for a
change released in e.g. 2.6.x to then also be released in a 2.7.x.
Best,
Andrew
On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
> > 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 release can
> be delayed after the release pass. Does it make sense to you?
>
> > Even if we have the branch-cut date in the version string, devs still
> need to be aware of other branches and backport appropriately.
>
> Yes, you're right. The good point of including date is that we can declare
> which version includes the latest changes. It helps users, not devs
> basically, to decide which version users will use: e.g. if
> 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> 2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
> against 2.7.3. Please let me know if I have some missing points.
>
> Thanks,
> - Tsuyoshi
>
> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>
>> Thanks for replies Akira and Tsuyoshi, inline:
>>
>> Akira: 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?
>>
>>
>> Yes, correct.
>>
>>
>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>
>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>> to maintainance branches after the date, users can find that which
>>> version
>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>
>>> Cons:-( A bit redundant.
>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>> our releases, when ordered chronologically, to incorporate all the known
>> relevant bug fixes. Even if we have the branch-cut date in the version
>> string, devs still need to be aware of other branches and backport
>> appropriately.
>>
>> Given that branch cuts and releases might not happen in the same order
>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>> for users. I bet many would assume it's the release date, like how Ubuntu
>> releases are numbered.
>>
>> Best,
>> Andrew
>>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
> 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 release can
be delayed after the release pass. Does it make sense to you?
> Even if we have the branch-cut date in the version string, devs still
need to be aware of other branches and backport appropriately.
Yes, you're right. The good point of including date is that we can declare
which version includes the latest changes. It helps users, not devs
basically, to decide which version users will use: e.g. if
2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
against 2.7.3. Please let me know if I have some missing points.
Thanks,
- Tsuyoshi
On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
> Thanks for replies Akira and Tsuyoshi, inline:
>
> Akira: 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?
>
>
> Yes, correct.
>
>
>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>
>> Pros:-) It's totally ordered. If we have a policy such as backporting
>> to maintainance branches after the date, users can find that which version
>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>> fixes which is not included in 3.0.0-alpha1-20160724.
>>
>> Cons:-( A bit redundant.
>>
>> Could you elaborate on the problem this scheme addresses? We always want
> our releases, when ordered chronologically, to incorporate all the known
> relevant bug fixes. Even if we have the branch-cut date in the version
> string, devs still need to be aware of other branches and backport
> appropriately.
>
> Given that branch cuts and releases might not happen in the same order
> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
> for users. I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Best,
> Andrew
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
> 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 release can
be delayed after the release pass. Does it make sense to you?
> Even if we have the branch-cut date in the version string, devs still
need to be aware of other branches and backport appropriately.
Yes, you're right. The good point of including date is that we can declare
which version includes the latest changes. It helps users, not devs
basically, to decide which version users will use: e.g. if
2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
against 2.7.3. Please let me know if I have some missing points.
Thanks,
- Tsuyoshi
On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
> Thanks for replies Akira and Tsuyoshi, inline:
>
> Akira: 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?
>
>
> Yes, correct.
>
>
>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>
>> Pros:-) It's totally ordered. If we have a policy such as backporting
>> to maintainance branches after the date, users can find that which version
>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>> fixes which is not included in 3.0.0-alpha1-20160724.
>>
>> Cons:-( A bit redundant.
>>
>> Could you elaborate on the problem this scheme addresses? We always want
> our releases, when ordered chronologically, to incorporate all the known
> relevant bug fixes. Even if we have the branch-cut date in the version
> string, devs still need to be aware of other branches and backport
> appropriately.
>
> Given that branch cuts and releases might not happen in the same order
> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
> for users. I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Best,
> Andrew
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
> 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 release can
be delayed after the release pass. Does it make sense to you?
> Even if we have the branch-cut date in the version string, devs still
need to be aware of other branches and backport appropriately.
Yes, you're right. The good point of including date is that we can declare
which version includes the latest changes. It helps users, not devs
basically, to decide which version users will use: e.g. if
2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
against 2.7.3. Please let me know if I have some missing points.
Thanks,
- Tsuyoshi
On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
> Thanks for replies Akira and Tsuyoshi, inline:
>
> Akira: 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?
>
>
> Yes, correct.
>
>
>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>
>> Pros:-) It's totally ordered. If we have a policy such as backporting
>> to maintainance branches after the date, users can find that which version
>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>> fixes which is not included in 3.0.0-alpha1-20160724.
>>
>> Cons:-( A bit redundant.
>>
>> Could you elaborate on the problem this scheme addresses? We always want
> our releases, when ordered chronologically, to incorporate all the known
> relevant bug fixes. Even if we have the branch-cut date in the version
> string, devs still need to be aware of other branches and backport
> appropriately.
>
> Given that branch cuts and releases might not happen in the same order
> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
> for users. I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Best,
> Andrew
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
> 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 release can
be delayed after the release pass. Does it make sense to you?
> Even if we have the branch-cut date in the version string, devs still
need to be aware of other branches and backport appropriately.
Yes, you're right. The good point of including date is that we can declare
which version includes the latest changes. It helps users, not devs
basically, to decide which version users will use: e.g. if
2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
against 2.7.3. Please let me know if I have some missing points.
Thanks,
- Tsuyoshi
On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
> Thanks for replies Akira and Tsuyoshi, inline:
>
> Akira: 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?
>
>
> Yes, correct.
>
>
>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>
>> Pros:-) It's totally ordered. If we have a policy such as backporting
>> to maintainance branches after the date, users can find that which version
>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>> fixes which is not included in 3.0.0-alpha1-20160724.
>>
>> Cons:-( A bit redundant.
>>
>> Could you elaborate on the problem this scheme addresses? We always want
> our releases, when ordered chronologically, to incorporate all the known
> relevant bug fixes. Even if we have the branch-cut date in the version
> string, devs still need to be aware of other branches and backport
> appropriately.
>
> Given that branch cuts and releases might not happen in the same order
> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
> for users. I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Best,
> Andrew
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Thanks for replies Akira and Tsuyoshi, inline:
Akira: 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?
Yes, correct.
> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>
> Pros:-) It's totally ordered. If we have a policy such as backporting
> to maintainance branches after the date, users can find that which version
> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
> fixes which is not included in 3.0.0-alpha1-20160724.
>
> Cons:-( A bit redundant.
>
> Could you elaborate on the problem this scheme addresses? We always want
our releases, when ordered chronologically, to incorporate all the known
relevant bug fixes. Even if we have the branch-cut date in the version
string, devs still need to be aware of other branches and backport
appropriately.
Given that branch cuts and releases might not happen in the same order
(e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
for users. I bet many would assume it's the release date, like how Ubuntu
releases are numbered.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Thanks for replies Akira and Tsuyoshi, inline:
Akira: 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?
Yes, correct.
> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>
> Pros:-) It's totally ordered. If we have a policy such as backporting
> to maintainance branches after the date, users can find that which version
> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
> fixes which is not included in 3.0.0-alpha1-20160724.
>
> Cons:-( A bit redundant.
>
> Could you elaborate on the problem this scheme addresses? We always want
our releases, when ordered chronologically, to incorporate all the known
relevant bug fixes. Even if we have the branch-cut date in the version
string, devs still need to be aware of other branches and backport
appropriately.
Given that branch cuts and releases might not happen in the same order
(e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
for users. I bet many would assume it's the release date, like how Ubuntu
releases are numbered.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Thanks for replies Akira and Tsuyoshi, inline:
Akira: 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?
Yes, correct.
> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>
> Pros:-) It's totally ordered. If we have a policy such as backporting
> to maintainance branches after the date, users can find that which version
> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
> fixes which is not included in 3.0.0-alpha1-20160724.
>
> Cons:-( A bit redundant.
>
> Could you elaborate on the problem this scheme addresses? We always want
our releases, when ordered chronologically, to incorporate all the known
relevant bug fixes. Even if we have the branch-cut date in the version
string, devs still need to be aware of other branches and backport
appropriately.
Given that branch cuts and releases might not happen in the same order
(e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
for users. I bet many would assume it's the release date, like how Ubuntu
releases are numbered.
Best,
Andrew
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
Thanks for replies Akira and Tsuyoshi, inline:
Akira: 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?
Yes, correct.
> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>
> Pros:-) It's totally ordered. If we have a policy such as backporting
> to maintainance branches after the date, users can find that which version
> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
> fixes which is not included in 3.0.0-alpha1-20160724.
>
> Cons:-( A bit redundant.
>
> Could you elaborate on the problem this scheme addresses? We always want
our releases, when ordered chronologically, to incorporate all the known
relevant bug fixes. Even if we have the branch-cut date in the version
string, devs still need to be aware of other branches and backport
appropriately.
Given that branch cuts and releases might not happen in the same order
(e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
for users. I bet many would assume it's the release date, like how Ubuntu
releases are numbered.
Best,
Andrew
[DISCUSS] Release numbering semantics with concurrent (>2) releases
[Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
Hi Vinod,
Thanks all guys for starting discussion!
My suggestion is adding the date when branch cut is done: like
3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
Pros:-) It's totally ordered. If we have a policy such as backporting
to maintainance branches after the date, users can find that which version
is cutting edge. In the example of above, 2.8.0-20160730 can include bug
fixes which is not included in 3.0.0-alpha1-20160724.
Cons:-( A bit redundant.
Thanks,
- Tsuyoshi
On Wednesday, 27 July 2016, Vinod Kumar Vavilapalli <vinodkv@apache.org
<javascript:_e(%7B%7D,'cvml','vinodkv@apache.org');>> wrote:
> 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 followed a simple
> timeline ordering. By this I mean that we always lined up releases one
> after another. Due to this, it was relatively simple to follow the causal
> ordering of releases, and we could answer ordering questions like “when was
> this patch first committed”.
>
> The first time this started getting hairy was with parallel 2.6.x and
> 2.7.x releases. We managed the confusion by ordering them one after
> another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked
> okay with two concurrent releases.
>
> Yes, by doing this, we could no longer answer questions by simply
> looking at the release numbers. But Sangjin / Junping / myself who did
> these 2.x releases ordered them one after another to avoid further
> confusion to developers and still retain the ability to just go back, look
> at the history and quickly answer the question of "what happened before and
> what happened after”. It wasn’t perfect, but we did what we did to keep it
> under control.
>
> # What’s coming
> Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this
> confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x,
> 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering
> becomes a nightmare. The related problems that were discussed in the
> original thread was about how we mark fix-versions for patches, and how we
> generate change-logs - the answers for both of these follow the solution to
> the root problem of concurrent releases.
>
> # Proposals?
> There were some discussions about semantic versioning in the thread
> form which I forked this one from, but it’s not clear to me how semantic
> versioning supports concurrent release trains.
>
> IAC, it’s time we look at this afresh and if need be, make some new rules
> before we make more of these releases and make it that much harder to
> follow for everyone.
>
> Thanks
> +Vinod
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
[DISCUSS] Release numbering semantics with concurrent (>2) releases
[Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
Hi Vinod,
Thanks all guys for starting discussion!
My suggestion is adding the date when branch cut is done: like
3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
Pros:-) It's totally ordered. If we have a policy such as backporting
to maintainance branches after the date, users can find that which version
is cutting edge. In the example of above, 2.8.0-20160730 can include bug
fixes which is not included in 3.0.0-alpha1-20160724.
Cons:-( A bit redundant.
Thanks,
- Tsuyoshi
On Wednesday, 27 July 2016, Vinod Kumar Vavilapalli <vinodkv@apache.org
<javascript:_e(%7B%7D,'cvml','vinodkv@apache.org');>> wrote:
> 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 followed a simple
> timeline ordering. By this I mean that we always lined up releases one
> after another. Due to this, it was relatively simple to follow the causal
> ordering of releases, and we could answer ordering questions like “when was
> this patch first committed”.
>
> The first time this started getting hairy was with parallel 2.6.x and
> 2.7.x releases. We managed the confusion by ordering them one after
> another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked
> okay with two concurrent releases.
>
> Yes, by doing this, we could no longer answer questions by simply
> looking at the release numbers. But Sangjin / Junping / myself who did
> these 2.x releases ordered them one after another to avoid further
> confusion to developers and still retain the ability to just go back, look
> at the history and quickly answer the question of "what happened before and
> what happened after”. It wasn’t perfect, but we did what we did to keep it
> under control.
>
> # What’s coming
> Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this
> confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x,
> 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering
> becomes a nightmare. The related problems that were discussed in the
> original thread was about how we mark fix-versions for patches, and how we
> generate change-logs - the answers for both of these follow the solution to
> the root problem of concurrent releases.
>
> # Proposals?
> There were some discussions about semantic versioning in the thread
> form which I forked this one from, but it’s not clear to me how semantic
> versioning supports concurrent release trains.
>
> IAC, it’s time we look at this afresh and if need be, make some new rules
> before we make more of these releases and make it that much harder to
> follow for everyone.
>
> Thanks
> +Vinod
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
[DISCUSS] Release numbering semantics with concurrent (>2) releases
[Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
Hi Vinod,
Thanks all guys for starting discussion!
My suggestion is adding the date when branch cut is done: like
3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
Pros:-) It's totally ordered. If we have a policy such as backporting
to maintainance branches after the date, users can find that which version
is cutting edge. In the example of above, 2.8.0-20160730 can include bug
fixes which is not included in 3.0.0-alpha1-20160724.
Cons:-( A bit redundant.
Thanks,
- Tsuyoshi
On Wednesday, 27 July 2016, Vinod Kumar Vavilapalli <vinodkv@apache.org
<javascript:_e(%7B%7D,'cvml','vinodkv@apache.org');>> wrote:
> 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 followed a simple
> timeline ordering. By this I mean that we always lined up releases one
> after another. Due to this, it was relatively simple to follow the causal
> ordering of releases, and we could answer ordering questions like “when was
> this patch first committed”.
>
> The first time this started getting hairy was with parallel 2.6.x and
> 2.7.x releases. We managed the confusion by ordering them one after
> another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked
> okay with two concurrent releases.
>
> Yes, by doing this, we could no longer answer questions by simply
> looking at the release numbers. But Sangjin / Junping / myself who did
> these 2.x releases ordered them one after another to avoid further
> confusion to developers and still retain the ability to just go back, look
> at the history and quickly answer the question of "what happened before and
> what happened after”. It wasn’t perfect, but we did what we did to keep it
> under control.
>
> # What’s coming
> Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this
> confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x,
> 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering
> becomes a nightmare. The related problems that were discussed in the
> original thread was about how we mark fix-versions for patches, and how we
> generate change-logs - the answers for both of these follow the solution to
> the root problem of concurrent releases.
>
> # Proposals?
> There were some discussions about semantic versioning in the thread
> form which I forked this one from, but it’s not clear to me how semantic
> versioning supports concurrent release trains.
>
> IAC, it’s time we look at this afresh and if need be, make some new rules
> before we make more of these releases and make it that much harder to
> follow for everyone.
>
> Thanks
> +Vinod
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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
[DISCUSS] Release numbering semantics with concurrent (>2) releases
[Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
Hi Vinod,
Thanks all guys for starting discussion!
My suggestion is adding the date when branch cut is done: like
3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
Pros:-) It's totally ordered. If we have a policy such as backporting
to maintainance branches after the date, users can find that which version
is cutting edge. In the example of above, 2.8.0-20160730 can include bug
fixes which is not included in 3.0.0-alpha1-20160724.
Cons:-( A bit redundant.
Thanks,
- Tsuyoshi
On Wednesday, 27 July 2016, Vinod Kumar Vavilapalli <vinodkv@apache.org
<javascript:_e(%7B%7D,'cvml','vinodkv@apache.org');>> wrote:
> 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 followed a simple
> timeline ordering. By this I mean that we always lined up releases one
> after another. Due to this, it was relatively simple to follow the causal
> ordering of releases, and we could answer ordering questions like “when was
> this patch first committed”.
>
> The first time this started getting hairy was with parallel 2.6.x and
> 2.7.x releases. We managed the confusion by ordering them one after
> another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked
> okay with two concurrent releases.
>
> Yes, by doing this, we could no longer answer questions by simply
> looking at the release numbers. But Sangjin / Junping / myself who did
> these 2.x releases ordered them one after another to avoid further
> confusion to developers and still retain the ability to just go back, look
> at the history and quickly answer the question of "what happened before and
> what happened after”. It wasn’t perfect, but we did what we did to keep it
> under control.
>
> # What’s coming
> Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this
> confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x,
> 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering
> becomes a nightmare. The related problems that were discussed in the
> original thread was about how we mark fix-versions for patches, and how we
> generate change-logs - the answers for both of these follow the solution to
> the root problem of concurrent releases.
>
> # Proposals?
> There were some discussions about semantic versioning in the thread
> form which I forked this one from, but it’s not clear to me how semantic
> versioning supports concurrent release trains.
>
> IAC, it’s time we look at this afresh and if need be, make some new rules
> before we make more of these releases and make it that much harder to
> follow for everyone.
>
> Thanks
> +Vinod
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [DISCUSS] Release numbering semantics with concurrent (>2)
releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Andrew Wang <an...@cloudera.com>.
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
[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
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 followed a simple timeline ordering. By this I mean that we always lined up releases one after another. Due to this, it was relatively simple to follow the causal ordering of releases, and we could answer ordering questions like “when was this patch first committed”.
The first time this started getting hairy was with parallel 2.6.x and 2.7.x releases. We managed the confusion by ordering them one after another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked okay with two concurrent releases.
Yes, by doing this, we could no longer answer questions by simply looking at the release numbers. But Sangjin / Junping / myself who did these 2.x releases ordered them one after another to avoid further confusion to developers and still retain the ability to just go back, look at the history and quickly answer the question of "what happened before and what happened after”. It wasn’t perfect, but we did what we did to keep it under control.
# What’s coming
Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x, 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering becomes a nightmare. The related problems that were discussed in the original thread was about how we mark fix-versions for patches, and how we generate change-logs - the answers for both of these follow the solution to the root problem of concurrent releases.
# Proposals?
There were some discussions about semantic versioning in the thread form which I forked this one from, but it’s not clear to me how semantic versioning supports concurrent release trains.
IAC, it’s time we look at this afresh and if need be, make some new rules before we make more of these releases and make it that much harder to follow for everyone.
Thanks
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
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 followed a simple timeline ordering. By this I mean that we always lined up releases one after another. Due to this, it was relatively simple to follow the causal ordering of releases, and we could answer ordering questions like “when was this patch first committed”.
The first time this started getting hairy was with parallel 2.6.x and 2.7.x releases. We managed the confusion by ordering them one after another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked okay with two concurrent releases.
Yes, by doing this, we could no longer answer questions by simply looking at the release numbers. But Sangjin / Junping / myself who did these 2.x releases ordered them one after another to avoid further confusion to developers and still retain the ability to just go back, look at the history and quickly answer the question of "what happened before and what happened after”. It wasn’t perfect, but we did what we did to keep it under control.
# What’s coming
Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x, 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering becomes a nightmare. The related problems that were discussed in the original thread was about how we mark fix-versions for patches, and how we generate change-logs - the answers for both of these follow the solution to the root problem of concurrent releases.
# Proposals?
There were some discussions about semantic versioning in the thread form which I forked this one from, but it’s not clear to me how semantic versioning supports concurrent release trains.
IAC, it’s time we look at this afresh and if need be, make some new rules before we make more of these releases and make it that much harder to follow for everyone.
Thanks
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
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 followed a simple timeline ordering. By this I mean that we always lined up releases one after another. Due to this, it was relatively simple to follow the causal ordering of releases, and we could answer ordering questions like “when was this patch first committed”.
The first time this started getting hairy was with parallel 2.6.x and 2.7.x releases. We managed the confusion by ordering them one after another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked okay with two concurrent releases.
Yes, by doing this, we could no longer answer questions by simply looking at the release numbers. But Sangjin / Junping / myself who did these 2.x releases ordered them one after another to avoid further confusion to developers and still retain the ability to just go back, look at the history and quickly answer the question of "what happened before and what happened after”. It wasn’t perfect, but we did what we did to keep it under control.
# What’s coming
Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x, 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering becomes a nightmare. The related problems that were discussed in the original thread was about how we mark fix-versions for patches, and how we generate change-logs - the answers for both of these follow the solution to the root problem of concurrent releases.
# Proposals?
There were some discussions about semantic versioning in the thread form which I forked this one from, but it’s not clear to me how semantic versioning supports concurrent release trains.
IAC, it’s time we look at this afresh and if need be, make some new rules before we make more of these releases and make it that much harder to follow for everyone.
Thanks
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
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 followed a simple timeline ordering. By this I mean that we always lined up releases one after another. Due to this, it was relatively simple to follow the causal ordering of releases, and we could answer ordering questions like “when was this patch first committed”.
The first time this started getting hairy was with parallel 2.6.x and 2.7.x releases. We managed the confusion by ordering them one after another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked okay with two concurrent releases.
Yes, by doing this, we could no longer answer questions by simply looking at the release numbers. But Sangjin / Junping / myself who did these 2.x releases ordered them one after another to avoid further confusion to developers and still retain the ability to just go back, look at the history and quickly answer the question of "what happened before and what happened after”. It wasn’t perfect, but we did what we did to keep it under control.
# What’s coming
Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x, 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering becomes a nightmare. The related problems that were discussed in the original thread was about how we mark fix-versions for patches, and how we generate change-logs - the answers for both of these follow the solution to the root problem of concurrent releases.
# Proposals?
There were some discussions about semantic versioning in the thread form which I forked this one from, but it’s not clear to me how semantic versioning supports concurrent release trains.
IAC, it’s time we look at this afresh and if need be, make some new rules before we make more of these releases and make it that much harder to follow for everyone.
Thanks
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Thanks Vinod+Wangda for the comments,
Above, Allen and I discussed a proposal which I think is reasonable and
also lines up well with our current approach. If you feel something is
underspecified or needs improvement, please raise those points.
We have been doing concurrent releases with the 2.6.x and 2.7.x lines, so
it's not entirely new ground. I believe we also haven't been doing
purely-chronological changelogs, since a JIRA can have fix versions of both
2.6.x and 2.7.x. The above proposal can be viewed as an extension of what
we're already doing for concurrent minor release branches to major release
branches.
The JIRA bulk update I want do to is add 3.0.0-alpha1 versions. Since we're
only adding, it won't affect the 2.8.0 or other release notes. I offered to
do a 2.8.0 JIRA bulk update since I already have the script, but I can also
just publish it and let someone else handle 2.8.0.
We do need to agree on the ordering of 2.8.0 and 3.0.0-alpha1 so 3's "base"
version makes sense chronologically. I'd like to base 3 off of 2.7.0, since
2.8.0 still has a number of unresolved blockers.
Finally, with some hackery, we've recently been able to compile the
projects in CDH against a Hadoop 3 snapshot. As part of the HDFS EC effort,
many contributors have already been testing Hadoop 3 snapshots on
multi-node clusters. So, I have confidence that what we have now is already
a useful artifact for downstreams, since downstreams are already trying to
consume it.
Best,
Andrew
On Mon, Jul 25, 2016 at 5:57 PM, Wangda Tan <wh...@gmail.com> wrote:
> Hi Andrew,
> Please wait updating fix version for branch-2 committed tickets before we
> get a consensus on this. Updating fix versions for them could bring lots of
> troubles for on going two releases (2.7.3 / 2.8.0).
>
> Thanks,
> Wangda
>
> On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
>> If I don't hear otherwise, I'd like to go ahead and do the bulk fix
>> version
>> update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
>> tomorrow in case there's more discussion. If any one is willing to help
>> review my script and JIRA queries, that'd also be great.
>>
>> I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
>> be a very similar process.
>>
>> Best,
>> Andrew
>>
>>
>> On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <
>> aw@effectivemachines.com>
>> wrote:
>>
>> >
>> > > On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> > >
>> > > Does this mean you find our current system of listing a JIRA as being
>> > fixed in both a 2.6.x and 2.7.x to be confusing?
>> >
>> > Nope. I'm only confused when there isn't a .0 release in the
>> fix
>> > line. When I see 2.6.x and 2.7.x I know that it was back ported to
>> those
>> > branches. If I don't see a .0, I figure it's either a mistake or
>> something
>> > that was already fixed by another change in that major/minor branch.
>> It's
>> > almost always the former, however.
>> >
>> > > FWIW, my usecase is normally not "what is the earliest release that
>> has
>> > this fix?" but rather "is this fix in this release?". If it's easy to
>> query
>> > the latter, you can also determine the former. Some kind of query tool
>> > could help here.
>> >
>> > It literally becomes a grep if people commit the release data
>> into
>> > the source tree, the release data is correct, etc:
>> >
>> > $ mvn install site -Preleasedocs -Pdocs -DskipTests
>> > $ grep issueid
>> > hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
>> >
>> > We should probably update the release process to make sure that
>> > *in progress* release data is also committed when a .0 is cut. That's
>> > likely missing. Another choice would be to modify the pom to that runs
>> > releasedocmaker to use a range rather than single version, but that
>> gets a
>> > bit tricky with release dates, how big of a range, etc. Not impossible,
>> > just tricky. Probably needs to be script that gets run as part of
>> > create-release, maybe?
>> >
>> > (In reality, I do this grep against my git repo that generates
>> the
>> > change log data automatically. This way it is always up-to-date and not
>> > dependent upon release data being committed. But that same grep could
>> be
>> > done with a JQL query just as easily.)
>> >
>> > > For the release notes, am I correct in interpreting this as:
>> > >
>> > > * diff a.0.0 from the previous x.y.0 release
>> > > * diff a.b.0 from the previous a.0.0 or a.b.0 release
>> > > * diff a.b.c from the previous a.b.0 or a.b.c release
>> >
>> > Pretty much yes.
>> >
>> > > Ray pointed me at the changelogs of a few other enterprise software
>> > products, and this strategy seems pretty common. I like it.
>> >
>> > It's extremely common, to the point that putting every fix for
>> > every release touched is, at least to me, weird and extremely
>> > unconventional.
>> >
>> > > I realize now that this means a lot more JIRAs will need the 2.8.0 fix
>> > version, since they only have 2.6.x and 2.7.x.
>> >
>> > Yup.
>> >
>> > > This makes the fix rules actually pretty easy: the lowest a.b.0
>> > release and all non-.0 releases.
>> > >
>> > > I think this needs to be amended to handle the case of multiple major
>> > release branches, since we could have something committed for both 2.9.0
>> > and 3.1.0. So "lowest a.b.0 release within each major version"?
>> >
>> > Yeah, switching to effectively trunk-based development makes the
>> > rules harder. It's one of the reasons why the two big enterprisey
>> > companies I worked at prior to working on Hadoop didn't really do
>> > trunk-based for the vast majority of projects. They always cut a branch
>> > (or equivalent for that SCM) to delineate a break. Given the amount of
>> > ex-Sun folks involved in the early days of Hadoop, our pre-existing
>> > development processes very much reflect that culture.
>> >
>> > > This was true previously (no releases from trunk, trunk is versioned
>> > a.0.0), but now that trunk is essentially a minor release branch, its
>> fix
>> > version needs to be treated as such.
>> >
>> > Yeah, I misspoke a bit when dealing with a head-of-tree model.
>> > 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
>> > Every 3.0.0-(label) release is effectively a major version in that case.
>> >
>> >
>> >
>>
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Thanks Vinod+Wangda for the comments,
Above, Allen and I discussed a proposal which I think is reasonable and
also lines up well with our current approach. If you feel something is
underspecified or needs improvement, please raise those points.
We have been doing concurrent releases with the 2.6.x and 2.7.x lines, so
it's not entirely new ground. I believe we also haven't been doing
purely-chronological changelogs, since a JIRA can have fix versions of both
2.6.x and 2.7.x. The above proposal can be viewed as an extension of what
we're already doing for concurrent minor release branches to major release
branches.
The JIRA bulk update I want do to is add 3.0.0-alpha1 versions. Since we're
only adding, it won't affect the 2.8.0 or other release notes. I offered to
do a 2.8.0 JIRA bulk update since I already have the script, but I can also
just publish it and let someone else handle 2.8.0.
We do need to agree on the ordering of 2.8.0 and 3.0.0-alpha1 so 3's "base"
version makes sense chronologically. I'd like to base 3 off of 2.7.0, since
2.8.0 still has a number of unresolved blockers.
Finally, with some hackery, we've recently been able to compile the
projects in CDH against a Hadoop 3 snapshot. As part of the HDFS EC effort,
many contributors have already been testing Hadoop 3 snapshots on
multi-node clusters. So, I have confidence that what we have now is already
a useful artifact for downstreams, since downstreams are already trying to
consume it.
Best,
Andrew
On Mon, Jul 25, 2016 at 5:57 PM, Wangda Tan <wh...@gmail.com> wrote:
> Hi Andrew,
> Please wait updating fix version for branch-2 committed tickets before we
> get a consensus on this. Updating fix versions for them could bring lots of
> troubles for on going two releases (2.7.3 / 2.8.0).
>
> Thanks,
> Wangda
>
> On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
>> If I don't hear otherwise, I'd like to go ahead and do the bulk fix
>> version
>> update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
>> tomorrow in case there's more discussion. If any one is willing to help
>> review my script and JIRA queries, that'd also be great.
>>
>> I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
>> be a very similar process.
>>
>> Best,
>> Andrew
>>
>>
>> On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <
>> aw@effectivemachines.com>
>> wrote:
>>
>> >
>> > > On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> > >
>> > > Does this mean you find our current system of listing a JIRA as being
>> > fixed in both a 2.6.x and 2.7.x to be confusing?
>> >
>> > Nope. I'm only confused when there isn't a .0 release in the
>> fix
>> > line. When I see 2.6.x and 2.7.x I know that it was back ported to
>> those
>> > branches. If I don't see a .0, I figure it's either a mistake or
>> something
>> > that was already fixed by another change in that major/minor branch.
>> It's
>> > almost always the former, however.
>> >
>> > > FWIW, my usecase is normally not "what is the earliest release that
>> has
>> > this fix?" but rather "is this fix in this release?". If it's easy to
>> query
>> > the latter, you can also determine the former. Some kind of query tool
>> > could help here.
>> >
>> > It literally becomes a grep if people commit the release data
>> into
>> > the source tree, the release data is correct, etc:
>> >
>> > $ mvn install site -Preleasedocs -Pdocs -DskipTests
>> > $ grep issueid
>> > hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
>> >
>> > We should probably update the release process to make sure that
>> > *in progress* release data is also committed when a .0 is cut. That's
>> > likely missing. Another choice would be to modify the pom to that runs
>> > releasedocmaker to use a range rather than single version, but that
>> gets a
>> > bit tricky with release dates, how big of a range, etc. Not impossible,
>> > just tricky. Probably needs to be script that gets run as part of
>> > create-release, maybe?
>> >
>> > (In reality, I do this grep against my git repo that generates
>> the
>> > change log data automatically. This way it is always up-to-date and not
>> > dependent upon release data being committed. But that same grep could
>> be
>> > done with a JQL query just as easily.)
>> >
>> > > For the release notes, am I correct in interpreting this as:
>> > >
>> > > * diff a.0.0 from the previous x.y.0 release
>> > > * diff a.b.0 from the previous a.0.0 or a.b.0 release
>> > > * diff a.b.c from the previous a.b.0 or a.b.c release
>> >
>> > Pretty much yes.
>> >
>> > > Ray pointed me at the changelogs of a few other enterprise software
>> > products, and this strategy seems pretty common. I like it.
>> >
>> > It's extremely common, to the point that putting every fix for
>> > every release touched is, at least to me, weird and extremely
>> > unconventional.
>> >
>> > > I realize now that this means a lot more JIRAs will need the 2.8.0 fix
>> > version, since they only have 2.6.x and 2.7.x.
>> >
>> > Yup.
>> >
>> > > This makes the fix rules actually pretty easy: the lowest a.b.0
>> > release and all non-.0 releases.
>> > >
>> > > I think this needs to be amended to handle the case of multiple major
>> > release branches, since we could have something committed for both 2.9.0
>> > and 3.1.0. So "lowest a.b.0 release within each major version"?
>> >
>> > Yeah, switching to effectively trunk-based development makes the
>> > rules harder. It's one of the reasons why the two big enterprisey
>> > companies I worked at prior to working on Hadoop didn't really do
>> > trunk-based for the vast majority of projects. They always cut a branch
>> > (or equivalent for that SCM) to delineate a break. Given the amount of
>> > ex-Sun folks involved in the early days of Hadoop, our pre-existing
>> > development processes very much reflect that culture.
>> >
>> > > This was true previously (no releases from trunk, trunk is versioned
>> > a.0.0), but now that trunk is essentially a minor release branch, its
>> fix
>> > version needs to be treated as such.
>> >
>> > Yeah, I misspoke a bit when dealing with a head-of-tree model.
>> > 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
>> > Every 3.0.0-(label) release is effectively a major version in that case.
>> >
>> >
>> >
>>
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Thanks Vinod+Wangda for the comments,
Above, Allen and I discussed a proposal which I think is reasonable and
also lines up well with our current approach. If you feel something is
underspecified or needs improvement, please raise those points.
We have been doing concurrent releases with the 2.6.x and 2.7.x lines, so
it's not entirely new ground. I believe we also haven't been doing
purely-chronological changelogs, since a JIRA can have fix versions of both
2.6.x and 2.7.x. The above proposal can be viewed as an extension of what
we're already doing for concurrent minor release branches to major release
branches.
The JIRA bulk update I want do to is add 3.0.0-alpha1 versions. Since we're
only adding, it won't affect the 2.8.0 or other release notes. I offered to
do a 2.8.0 JIRA bulk update since I already have the script, but I can also
just publish it and let someone else handle 2.8.0.
We do need to agree on the ordering of 2.8.0 and 3.0.0-alpha1 so 3's "base"
version makes sense chronologically. I'd like to base 3 off of 2.7.0, since
2.8.0 still has a number of unresolved blockers.
Finally, with some hackery, we've recently been able to compile the
projects in CDH against a Hadoop 3 snapshot. As part of the HDFS EC effort,
many contributors have already been testing Hadoop 3 snapshots on
multi-node clusters. So, I have confidence that what we have now is already
a useful artifact for downstreams, since downstreams are already trying to
consume it.
Best,
Andrew
On Mon, Jul 25, 2016 at 5:57 PM, Wangda Tan <wh...@gmail.com> wrote:
> Hi Andrew,
> Please wait updating fix version for branch-2 committed tickets before we
> get a consensus on this. Updating fix versions for them could bring lots of
> troubles for on going two releases (2.7.3 / 2.8.0).
>
> Thanks,
> Wangda
>
> On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
>> If I don't hear otherwise, I'd like to go ahead and do the bulk fix
>> version
>> update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
>> tomorrow in case there's more discussion. If any one is willing to help
>> review my script and JIRA queries, that'd also be great.
>>
>> I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
>> be a very similar process.
>>
>> Best,
>> Andrew
>>
>>
>> On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <
>> aw@effectivemachines.com>
>> wrote:
>>
>> >
>> > > On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> > >
>> > > Does this mean you find our current system of listing a JIRA as being
>> > fixed in both a 2.6.x and 2.7.x to be confusing?
>> >
>> > Nope. I'm only confused when there isn't a .0 release in the
>> fix
>> > line. When I see 2.6.x and 2.7.x I know that it was back ported to
>> those
>> > branches. If I don't see a .0, I figure it's either a mistake or
>> something
>> > that was already fixed by another change in that major/minor branch.
>> It's
>> > almost always the former, however.
>> >
>> > > FWIW, my usecase is normally not "what is the earliest release that
>> has
>> > this fix?" but rather "is this fix in this release?". If it's easy to
>> query
>> > the latter, you can also determine the former. Some kind of query tool
>> > could help here.
>> >
>> > It literally becomes a grep if people commit the release data
>> into
>> > the source tree, the release data is correct, etc:
>> >
>> > $ mvn install site -Preleasedocs -Pdocs -DskipTests
>> > $ grep issueid
>> > hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
>> >
>> > We should probably update the release process to make sure that
>> > *in progress* release data is also committed when a .0 is cut. That's
>> > likely missing. Another choice would be to modify the pom to that runs
>> > releasedocmaker to use a range rather than single version, but that
>> gets a
>> > bit tricky with release dates, how big of a range, etc. Not impossible,
>> > just tricky. Probably needs to be script that gets run as part of
>> > create-release, maybe?
>> >
>> > (In reality, I do this grep against my git repo that generates
>> the
>> > change log data automatically. This way it is always up-to-date and not
>> > dependent upon release data being committed. But that same grep could
>> be
>> > done with a JQL query just as easily.)
>> >
>> > > For the release notes, am I correct in interpreting this as:
>> > >
>> > > * diff a.0.0 from the previous x.y.0 release
>> > > * diff a.b.0 from the previous a.0.0 or a.b.0 release
>> > > * diff a.b.c from the previous a.b.0 or a.b.c release
>> >
>> > Pretty much yes.
>> >
>> > > Ray pointed me at the changelogs of a few other enterprise software
>> > products, and this strategy seems pretty common. I like it.
>> >
>> > It's extremely common, to the point that putting every fix for
>> > every release touched is, at least to me, weird and extremely
>> > unconventional.
>> >
>> > > I realize now that this means a lot more JIRAs will need the 2.8.0 fix
>> > version, since they only have 2.6.x and 2.7.x.
>> >
>> > Yup.
>> >
>> > > This makes the fix rules actually pretty easy: the lowest a.b.0
>> > release and all non-.0 releases.
>> > >
>> > > I think this needs to be amended to handle the case of multiple major
>> > release branches, since we could have something committed for both 2.9.0
>> > and 3.1.0. So "lowest a.b.0 release within each major version"?
>> >
>> > Yeah, switching to effectively trunk-based development makes the
>> > rules harder. It's one of the reasons why the two big enterprisey
>> > companies I worked at prior to working on Hadoop didn't really do
>> > trunk-based for the vast majority of projects. They always cut a branch
>> > (or equivalent for that SCM) to delineate a break. Given the amount of
>> > ex-Sun folks involved in the early days of Hadoop, our pre-existing
>> > development processes very much reflect that culture.
>> >
>> > > This was true previously (no releases from trunk, trunk is versioned
>> > a.0.0), but now that trunk is essentially a minor release branch, its
>> fix
>> > version needs to be treated as such.
>> >
>> > Yeah, I misspoke a bit when dealing with a head-of-tree model.
>> > 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
>> > Every 3.0.0-(label) release is effectively a major version in that case.
>> >
>> >
>> >
>>
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
Hi Andrew,
Please wait updating fix version for branch-2 committed tickets before we
get a consensus on this. Updating fix versions for them could bring lots of
troubles for on going two releases (2.7.3 / 2.8.0).
Thanks,
Wangda
On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang <an...@cloudera.com>
wrote:
> If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
> update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
> tomorrow in case there's more discussion. If any one is willing to help
> review my script and JIRA queries, that'd also be great.
>
> I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
> be a very similar process.
>
> Best,
> Andrew
>
>
> On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <
> aw@effectivemachines.com>
> wrote:
>
> >
> > > On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >
> > > Does this mean you find our current system of listing a JIRA as being
> > fixed in both a 2.6.x and 2.7.x to be confusing?
> >
> > Nope. I'm only confused when there isn't a .0 release in the fix
> > line. When I see 2.6.x and 2.7.x I know that it was back ported to those
> > branches. If I don't see a .0, I figure it's either a mistake or
> something
> > that was already fixed by another change in that major/minor branch.
> It's
> > almost always the former, however.
> >
> > > FWIW, my usecase is normally not "what is the earliest release that has
> > this fix?" but rather "is this fix in this release?". If it's easy to
> query
> > the latter, you can also determine the former. Some kind of query tool
> > could help here.
> >
> > It literally becomes a grep if people commit the release data
> into
> > the source tree, the release data is correct, etc:
> >
> > $ mvn install site -Preleasedocs -Pdocs -DskipTests
> > $ grep issueid
> > hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
> >
> > We should probably update the release process to make sure that
> > *in progress* release data is also committed when a .0 is cut. That's
> > likely missing. Another choice would be to modify the pom to that runs
> > releasedocmaker to use a range rather than single version, but that gets
> a
> > bit tricky with release dates, how big of a range, etc. Not impossible,
> > just tricky. Probably needs to be script that gets run as part of
> > create-release, maybe?
> >
> > (In reality, I do this grep against my git repo that generates
> the
> > change log data automatically. This way it is always up-to-date and not
> > dependent upon release data being committed. But that same grep could be
> > done with a JQL query just as easily.)
> >
> > > For the release notes, am I correct in interpreting this as:
> > >
> > > * diff a.0.0 from the previous x.y.0 release
> > > * diff a.b.0 from the previous a.0.0 or a.b.0 release
> > > * diff a.b.c from the previous a.b.0 or a.b.c release
> >
> > Pretty much yes.
> >
> > > Ray pointed me at the changelogs of a few other enterprise software
> > products, and this strategy seems pretty common. I like it.
> >
> > It's extremely common, to the point that putting every fix for
> > every release touched is, at least to me, weird and extremely
> > unconventional.
> >
> > > I realize now that this means a lot more JIRAs will need the 2.8.0 fix
> > version, since they only have 2.6.x and 2.7.x.
> >
> > Yup.
> >
> > > This makes the fix rules actually pretty easy: the lowest a.b.0
> > release and all non-.0 releases.
> > >
> > > I think this needs to be amended to handle the case of multiple major
> > release branches, since we could have something committed for both 2.9.0
> > and 3.1.0. So "lowest a.b.0 release within each major version"?
> >
> > Yeah, switching to effectively trunk-based development makes the
> > rules harder. It's one of the reasons why the two big enterprisey
> > companies I worked at prior to working on Hadoop didn't really do
> > trunk-based for the vast majority of projects. They always cut a branch
> > (or equivalent for that SCM) to delineate a break. Given the amount of
> > ex-Sun folks involved in the early days of Hadoop, our pre-existing
> > development processes very much reflect that culture.
> >
> > > This was true previously (no releases from trunk, trunk is versioned
> > a.0.0), but now that trunk is essentially a minor release branch, its fix
> > version needs to be treated as such.
> >
> > Yeah, I misspoke a bit when dealing with a head-of-tree model.
> > 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
> > Every 3.0.0-(label) release is effectively a major version in that case.
> >
> >
> >
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
Hi Andrew,
Please wait updating fix version for branch-2 committed tickets before we
get a consensus on this. Updating fix versions for them could bring lots of
troubles for on going two releases (2.7.3 / 2.8.0).
Thanks,
Wangda
On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang <an...@cloudera.com>
wrote:
> If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
> update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
> tomorrow in case there's more discussion. If any one is willing to help
> review my script and JIRA queries, that'd also be great.
>
> I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
> be a very similar process.
>
> Best,
> Andrew
>
>
> On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <
> aw@effectivemachines.com>
> wrote:
>
> >
> > > On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >
> > > Does this mean you find our current system of listing a JIRA as being
> > fixed in both a 2.6.x and 2.7.x to be confusing?
> >
> > Nope. I'm only confused when there isn't a .0 release in the fix
> > line. When I see 2.6.x and 2.7.x I know that it was back ported to those
> > branches. If I don't see a .0, I figure it's either a mistake or
> something
> > that was already fixed by another change in that major/minor branch.
> It's
> > almost always the former, however.
> >
> > > FWIW, my usecase is normally not "what is the earliest release that has
> > this fix?" but rather "is this fix in this release?". If it's easy to
> query
> > the latter, you can also determine the former. Some kind of query tool
> > could help here.
> >
> > It literally becomes a grep if people commit the release data
> into
> > the source tree, the release data is correct, etc:
> >
> > $ mvn install site -Preleasedocs -Pdocs -DskipTests
> > $ grep issueid
> > hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
> >
> > We should probably update the release process to make sure that
> > *in progress* release data is also committed when a .0 is cut. That's
> > likely missing. Another choice would be to modify the pom to that runs
> > releasedocmaker to use a range rather than single version, but that gets
> a
> > bit tricky with release dates, how big of a range, etc. Not impossible,
> > just tricky. Probably needs to be script that gets run as part of
> > create-release, maybe?
> >
> > (In reality, I do this grep against my git repo that generates
> the
> > change log data automatically. This way it is always up-to-date and not
> > dependent upon release data being committed. But that same grep could be
> > done with a JQL query just as easily.)
> >
> > > For the release notes, am I correct in interpreting this as:
> > >
> > > * diff a.0.0 from the previous x.y.0 release
> > > * diff a.b.0 from the previous a.0.0 or a.b.0 release
> > > * diff a.b.c from the previous a.b.0 or a.b.c release
> >
> > Pretty much yes.
> >
> > > Ray pointed me at the changelogs of a few other enterprise software
> > products, and this strategy seems pretty common. I like it.
> >
> > It's extremely common, to the point that putting every fix for
> > every release touched is, at least to me, weird and extremely
> > unconventional.
> >
> > > I realize now that this means a lot more JIRAs will need the 2.8.0 fix
> > version, since they only have 2.6.x and 2.7.x.
> >
> > Yup.
> >
> > > This makes the fix rules actually pretty easy: the lowest a.b.0
> > release and all non-.0 releases.
> > >
> > > I think this needs to be amended to handle the case of multiple major
> > release branches, since we could have something committed for both 2.9.0
> > and 3.1.0. So "lowest a.b.0 release within each major version"?
> >
> > Yeah, switching to effectively trunk-based development makes the
> > rules harder. It's one of the reasons why the two big enterprisey
> > companies I worked at prior to working on Hadoop didn't really do
> > trunk-based for the vast majority of projects. They always cut a branch
> > (or equivalent for that SCM) to delineate a break. Given the amount of
> > ex-Sun folks involved in the early days of Hadoop, our pre-existing
> > development processes very much reflect that culture.
> >
> > > This was true previously (no releases from trunk, trunk is versioned
> > a.0.0), but now that trunk is essentially a minor release branch, its fix
> > version needs to be treated as such.
> >
> > Yeah, I misspoke a bit when dealing with a head-of-tree model.
> > 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
> > Every 3.0.0-(label) release is effectively a major version in that case.
> >
> >
> >
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
Please don’t do this for 2.8.0 against 2.7.0 till we change our existing release ordering conventions.
Till now, I made sure 2.8.0 only has issues that are not in 2.7.3 - per the 2.8.0-follows-2.7.3 convention. As part of the release process, I will fix the remaining tickets to follow this same convention. Again till we create new rules.
Thanks
+Vinod
> On Jul 25, 2016, at 11:02 AM, Andrew Wang <an...@cloudera.com> wrote:
>
> If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
> update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
> tomorrow in case there's more discussion. If any one is willing to help
> review my script and JIRA queries, that'd also be great.
>
> I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
> be a very similar process.
>
> Best,
> Andrew
>
>
> On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <aw...@effectivemachines.com>
> wrote:
>
>>
>>> On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
>> wrote:
>>>
>>> Does this mean you find our current system of listing a JIRA as being
>> fixed in both a 2.6.x and 2.7.x to be confusing?
>>
>> Nope. I'm only confused when there isn't a .0 release in the fix
>> line. When I see 2.6.x and 2.7.x I know that it was back ported to those
>> branches. If I don't see a .0, I figure it's either a mistake or something
>> that was already fixed by another change in that major/minor branch. It's
>> almost always the former, however.
>>
>>> FWIW, my usecase is normally not "what is the earliest release that has
>> this fix?" but rather "is this fix in this release?". If it's easy to query
>> the latter, you can also determine the former. Some kind of query tool
>> could help here.
>>
>> It literally becomes a grep if people commit the release data into
>> the source tree, the release data is correct, etc:
>>
>> $ mvn install site -Preleasedocs -Pdocs -DskipTests
>> $ grep issueid
>> hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
>>
>> We should probably update the release process to make sure that
>> *in progress* release data is also committed when a .0 is cut. That's
>> likely missing. Another choice would be to modify the pom to that runs
>> releasedocmaker to use a range rather than single version, but that gets a
>> bit tricky with release dates, how big of a range, etc. Not impossible,
>> just tricky. Probably needs to be script that gets run as part of
>> create-release, maybe?
>>
>> (In reality, I do this grep against my git repo that generates the
>> change log data automatically. This way it is always up-to-date and not
>> dependent upon release data being committed. But that same grep could be
>> done with a JQL query just as easily.)
>>
>>> For the release notes, am I correct in interpreting this as:
>>>
>>> * diff a.0.0 from the previous x.y.0 release
>>> * diff a.b.0 from the previous a.0.0 or a.b.0 release
>>> * diff a.b.c from the previous a.b.0 or a.b.c release
>>
>> Pretty much yes.
>>
>>> Ray pointed me at the changelogs of a few other enterprise software
>> products, and this strategy seems pretty common. I like it.
>>
>> It's extremely common, to the point that putting every fix for
>> every release touched is, at least to me, weird and extremely
>> unconventional.
>>
>>> I realize now that this means a lot more JIRAs will need the 2.8.0 fix
>> version, since they only have 2.6.x and 2.7.x.
>>
>> Yup.
>>
>>> This makes the fix rules actually pretty easy: the lowest a.b.0
>> release and all non-.0 releases.
>>>
>>> I think this needs to be amended to handle the case of multiple major
>> release branches, since we could have something committed for both 2.9.0
>> and 3.1.0. So "lowest a.b.0 release within each major version"?
>>
>> Yeah, switching to effectively trunk-based development makes the
>> rules harder. It's one of the reasons why the two big enterprisey
>> companies I worked at prior to working on Hadoop didn't really do
>> trunk-based for the vast majority of projects. They always cut a branch
>> (or equivalent for that SCM) to delineate a break. Given the amount of
>> ex-Sun folks involved in the early days of Hadoop, our pre-existing
>> development processes very much reflect that culture.
>>
>>> This was true previously (no releases from trunk, trunk is versioned
>> a.0.0), but now that trunk is essentially a minor release branch, its fix
>> version needs to be treated as such.
>>
>> Yeah, I misspoke a bit when dealing with a head-of-tree model.
>> 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
>> Every 3.0.0-(label) release is effectively a major version in that case.
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Wangda Tan <wh...@gmail.com>.
Hi Andrew,
Please wait updating fix version for branch-2 committed tickets before we
get a consensus on this. Updating fix versions for them could bring lots of
troubles for on going two releases (2.7.3 / 2.8.0).
Thanks,
Wangda
On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang <an...@cloudera.com>
wrote:
> If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
> update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
> tomorrow in case there's more discussion. If any one is willing to help
> review my script and JIRA queries, that'd also be great.
>
> I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
> be a very similar process.
>
> Best,
> Andrew
>
>
> On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <
> aw@effectivemachines.com>
> wrote:
>
> >
> > > On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >
> > > Does this mean you find our current system of listing a JIRA as being
> > fixed in both a 2.6.x and 2.7.x to be confusing?
> >
> > Nope. I'm only confused when there isn't a .0 release in the fix
> > line. When I see 2.6.x and 2.7.x I know that it was back ported to those
> > branches. If I don't see a .0, I figure it's either a mistake or
> something
> > that was already fixed by another change in that major/minor branch.
> It's
> > almost always the former, however.
> >
> > > FWIW, my usecase is normally not "what is the earliest release that has
> > this fix?" but rather "is this fix in this release?". If it's easy to
> query
> > the latter, you can also determine the former. Some kind of query tool
> > could help here.
> >
> > It literally becomes a grep if people commit the release data
> into
> > the source tree, the release data is correct, etc:
> >
> > $ mvn install site -Preleasedocs -Pdocs -DskipTests
> > $ grep issueid
> > hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
> >
> > We should probably update the release process to make sure that
> > *in progress* release data is also committed when a .0 is cut. That's
> > likely missing. Another choice would be to modify the pom to that runs
> > releasedocmaker to use a range rather than single version, but that gets
> a
> > bit tricky with release dates, how big of a range, etc. Not impossible,
> > just tricky. Probably needs to be script that gets run as part of
> > create-release, maybe?
> >
> > (In reality, I do this grep against my git repo that generates
> the
> > change log data automatically. This way it is always up-to-date and not
> > dependent upon release data being committed. But that same grep could be
> > done with a JQL query just as easily.)
> >
> > > For the release notes, am I correct in interpreting this as:
> > >
> > > * diff a.0.0 from the previous x.y.0 release
> > > * diff a.b.0 from the previous a.0.0 or a.b.0 release
> > > * diff a.b.c from the previous a.b.0 or a.b.c release
> >
> > Pretty much yes.
> >
> > > Ray pointed me at the changelogs of a few other enterprise software
> > products, and this strategy seems pretty common. I like it.
> >
> > It's extremely common, to the point that putting every fix for
> > every release touched is, at least to me, weird and extremely
> > unconventional.
> >
> > > I realize now that this means a lot more JIRAs will need the 2.8.0 fix
> > version, since they only have 2.6.x and 2.7.x.
> >
> > Yup.
> >
> > > This makes the fix rules actually pretty easy: the lowest a.b.0
> > release and all non-.0 releases.
> > >
> > > I think this needs to be amended to handle the case of multiple major
> > release branches, since we could have something committed for both 2.9.0
> > and 3.1.0. So "lowest a.b.0 release within each major version"?
> >
> > Yeah, switching to effectively trunk-based development makes the
> > rules harder. It's one of the reasons why the two big enterprisey
> > companies I worked at prior to working on Hadoop didn't really do
> > trunk-based for the vast majority of projects. They always cut a branch
> > (or equivalent for that SCM) to delineate a break. Given the amount of
> > ex-Sun folks involved in the early days of Hadoop, our pre-existing
> > development processes very much reflect that culture.
> >
> > > This was true previously (no releases from trunk, trunk is versioned
> > a.0.0), but now that trunk is essentially a minor release branch, its fix
> > version needs to be treated as such.
> >
> > Yeah, I misspoke a bit when dealing with a head-of-tree model.
> > 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
> > Every 3.0.0-(label) release is effectively a major version in that case.
> >
> >
> >
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
Please don’t do this for 2.8.0 against 2.7.0 till we change our existing release ordering conventions.
Till now, I made sure 2.8.0 only has issues that are not in 2.7.3 - per the 2.8.0-follows-2.7.3 convention. As part of the release process, I will fix the remaining tickets to follow this same convention. Again till we create new rules.
Thanks
+Vinod
> On Jul 25, 2016, at 11:02 AM, Andrew Wang <an...@cloudera.com> wrote:
>
> If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
> update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
> tomorrow in case there's more discussion. If any one is willing to help
> review my script and JIRA queries, that'd also be great.
>
> I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
> be a very similar process.
>
> Best,
> Andrew
>
>
> On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <aw...@effectivemachines.com>
> wrote:
>
>>
>>> On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
>> wrote:
>>>
>>> Does this mean you find our current system of listing a JIRA as being
>> fixed in both a 2.6.x and 2.7.x to be confusing?
>>
>> Nope. I'm only confused when there isn't a .0 release in the fix
>> line. When I see 2.6.x and 2.7.x I know that it was back ported to those
>> branches. If I don't see a .0, I figure it's either a mistake or something
>> that was already fixed by another change in that major/minor branch. It's
>> almost always the former, however.
>>
>>> FWIW, my usecase is normally not "what is the earliest release that has
>> this fix?" but rather "is this fix in this release?". If it's easy to query
>> the latter, you can also determine the former. Some kind of query tool
>> could help here.
>>
>> It literally becomes a grep if people commit the release data into
>> the source tree, the release data is correct, etc:
>>
>> $ mvn install site -Preleasedocs -Pdocs -DskipTests
>> $ grep issueid
>> hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
>>
>> We should probably update the release process to make sure that
>> *in progress* release data is also committed when a .0 is cut. That's
>> likely missing. Another choice would be to modify the pom to that runs
>> releasedocmaker to use a range rather than single version, but that gets a
>> bit tricky with release dates, how big of a range, etc. Not impossible,
>> just tricky. Probably needs to be script that gets run as part of
>> create-release, maybe?
>>
>> (In reality, I do this grep against my git repo that generates the
>> change log data automatically. This way it is always up-to-date and not
>> dependent upon release data being committed. But that same grep could be
>> done with a JQL query just as easily.)
>>
>>> For the release notes, am I correct in interpreting this as:
>>>
>>> * diff a.0.0 from the previous x.y.0 release
>>> * diff a.b.0 from the previous a.0.0 or a.b.0 release
>>> * diff a.b.c from the previous a.b.0 or a.b.c release
>>
>> Pretty much yes.
>>
>>> Ray pointed me at the changelogs of a few other enterprise software
>> products, and this strategy seems pretty common. I like it.
>>
>> It's extremely common, to the point that putting every fix for
>> every release touched is, at least to me, weird and extremely
>> unconventional.
>>
>>> I realize now that this means a lot more JIRAs will need the 2.8.0 fix
>> version, since they only have 2.6.x and 2.7.x.
>>
>> Yup.
>>
>>> This makes the fix rules actually pretty easy: the lowest a.b.0
>> release and all non-.0 releases.
>>>
>>> I think this needs to be amended to handle the case of multiple major
>> release branches, since we could have something committed for both 2.9.0
>> and 3.1.0. So "lowest a.b.0 release within each major version"?
>>
>> Yeah, switching to effectively trunk-based development makes the
>> rules harder. It's one of the reasons why the two big enterprisey
>> companies I worked at prior to working on Hadoop didn't really do
>> trunk-based for the vast majority of projects. They always cut a branch
>> (or equivalent for that SCM) to delineate a break. Given the amount of
>> ex-Sun folks involved in the early days of Hadoop, our pre-existing
>> development processes very much reflect that culture.
>>
>>> This was true previously (no releases from trunk, trunk is versioned
>> a.0.0), but now that trunk is essentially a minor release branch, its fix
>> version needs to be treated as such.
>>
>> Yeah, I misspoke a bit when dealing with a head-of-tree model.
>> 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
>> Every 3.0.0-(label) release is effectively a major version in that case.
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
Please don’t do this for 2.8.0 against 2.7.0 till we change our existing release ordering conventions.
Till now, I made sure 2.8.0 only has issues that are not in 2.7.3 - per the 2.8.0-follows-2.7.3 convention. As part of the release process, I will fix the remaining tickets to follow this same convention. Again till we create new rules.
Thanks
+Vinod
> On Jul 25, 2016, at 11:02 AM, Andrew Wang <an...@cloudera.com> wrote:
>
> If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
> update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
> tomorrow in case there's more discussion. If any one is willing to help
> review my script and JIRA queries, that'd also be great.
>
> I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
> be a very similar process.
>
> Best,
> Andrew
>
>
> On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <aw...@effectivemachines.com>
> wrote:
>
>>
>>> On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
>> wrote:
>>>
>>> Does this mean you find our current system of listing a JIRA as being
>> fixed in both a 2.6.x and 2.7.x to be confusing?
>>
>> Nope. I'm only confused when there isn't a .0 release in the fix
>> line. When I see 2.6.x and 2.7.x I know that it was back ported to those
>> branches. If I don't see a .0, I figure it's either a mistake or something
>> that was already fixed by another change in that major/minor branch. It's
>> almost always the former, however.
>>
>>> FWIW, my usecase is normally not "what is the earliest release that has
>> this fix?" but rather "is this fix in this release?". If it's easy to query
>> the latter, you can also determine the former. Some kind of query tool
>> could help here.
>>
>> It literally becomes a grep if people commit the release data into
>> the source tree, the release data is correct, etc:
>>
>> $ mvn install site -Preleasedocs -Pdocs -DskipTests
>> $ grep issueid
>> hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
>>
>> We should probably update the release process to make sure that
>> *in progress* release data is also committed when a .0 is cut. That's
>> likely missing. Another choice would be to modify the pom to that runs
>> releasedocmaker to use a range rather than single version, but that gets a
>> bit tricky with release dates, how big of a range, etc. Not impossible,
>> just tricky. Probably needs to be script that gets run as part of
>> create-release, maybe?
>>
>> (In reality, I do this grep against my git repo that generates the
>> change log data automatically. This way it is always up-to-date and not
>> dependent upon release data being committed. But that same grep could be
>> done with a JQL query just as easily.)
>>
>>> For the release notes, am I correct in interpreting this as:
>>>
>>> * diff a.0.0 from the previous x.y.0 release
>>> * diff a.b.0 from the previous a.0.0 or a.b.0 release
>>> * diff a.b.c from the previous a.b.0 or a.b.c release
>>
>> Pretty much yes.
>>
>>> Ray pointed me at the changelogs of a few other enterprise software
>> products, and this strategy seems pretty common. I like it.
>>
>> It's extremely common, to the point that putting every fix for
>> every release touched is, at least to me, weird and extremely
>> unconventional.
>>
>>> I realize now that this means a lot more JIRAs will need the 2.8.0 fix
>> version, since they only have 2.6.x and 2.7.x.
>>
>> Yup.
>>
>>> This makes the fix rules actually pretty easy: the lowest a.b.0
>> release and all non-.0 releases.
>>>
>>> I think this needs to be amended to handle the case of multiple major
>> release branches, since we could have something committed for both 2.9.0
>> and 3.1.0. So "lowest a.b.0 release within each major version"?
>>
>> Yeah, switching to effectively trunk-based development makes the
>> rules harder. It's one of the reasons why the two big enterprisey
>> companies I worked at prior to working on Hadoop didn't really do
>> trunk-based for the vast majority of projects. They always cut a branch
>> (or equivalent for that SCM) to delineate a break. Given the amount of
>> ex-Sun folks involved in the early days of Hadoop, our pre-existing
>> development processes very much reflect that culture.
>>
>>> This was true previously (no releases from trunk, trunk is versioned
>> a.0.0), but now that trunk is essentially a minor release branch, its fix
>> version needs to be treated as such.
>>
>> Yeah, I misspoke a bit when dealing with a head-of-tree model.
>> 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
>> Every 3.0.0-(label) release is effectively a major version in that case.
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
tomorrow in case there's more discussion. If any one is willing to help
review my script and JIRA queries, that'd also be great.
I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
be a very similar process.
Best,
Andrew
On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> > Does this mean you find our current system of listing a JIRA as being
> fixed in both a 2.6.x and 2.7.x to be confusing?
>
> Nope. I'm only confused when there isn't a .0 release in the fix
> line. When I see 2.6.x and 2.7.x I know that it was back ported to those
> branches. If I don't see a .0, I figure it's either a mistake or something
> that was already fixed by another change in that major/minor branch. It's
> almost always the former, however.
>
> > FWIW, my usecase is normally not "what is the earliest release that has
> this fix?" but rather "is this fix in this release?". If it's easy to query
> the latter, you can also determine the former. Some kind of query tool
> could help here.
>
> It literally becomes a grep if people commit the release data into
> the source tree, the release data is correct, etc:
>
> $ mvn install site -Preleasedocs -Pdocs -DskipTests
> $ grep issueid
> hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
>
> We should probably update the release process to make sure that
> *in progress* release data is also committed when a .0 is cut. That's
> likely missing. Another choice would be to modify the pom to that runs
> releasedocmaker to use a range rather than single version, but that gets a
> bit tricky with release dates, how big of a range, etc. Not impossible,
> just tricky. Probably needs to be script that gets run as part of
> create-release, maybe?
>
> (In reality, I do this grep against my git repo that generates the
> change log data automatically. This way it is always up-to-date and not
> dependent upon release data being committed. But that same grep could be
> done with a JQL query just as easily.)
>
> > For the release notes, am I correct in interpreting this as:
> >
> > * diff a.0.0 from the previous x.y.0 release
> > * diff a.b.0 from the previous a.0.0 or a.b.0 release
> > * diff a.b.c from the previous a.b.0 or a.b.c release
>
> Pretty much yes.
>
> > Ray pointed me at the changelogs of a few other enterprise software
> products, and this strategy seems pretty common. I like it.
>
> It's extremely common, to the point that putting every fix for
> every release touched is, at least to me, weird and extremely
> unconventional.
>
> > I realize now that this means a lot more JIRAs will need the 2.8.0 fix
> version, since they only have 2.6.x and 2.7.x.
>
> Yup.
>
> > This makes the fix rules actually pretty easy: the lowest a.b.0
> release and all non-.0 releases.
> >
> > I think this needs to be amended to handle the case of multiple major
> release branches, since we could have something committed for both 2.9.0
> and 3.1.0. So "lowest a.b.0 release within each major version"?
>
> Yeah, switching to effectively trunk-based development makes the
> rules harder. It's one of the reasons why the two big enterprisey
> companies I worked at prior to working on Hadoop didn't really do
> trunk-based for the vast majority of projects. They always cut a branch
> (or equivalent for that SCM) to delineate a break. Given the amount of
> ex-Sun folks involved in the early days of Hadoop, our pre-existing
> development processes very much reflect that culture.
>
> > This was true previously (no releases from trunk, trunk is versioned
> a.0.0), but now that trunk is essentially a minor release branch, its fix
> version needs to be treated as such.
>
> Yeah, I misspoke a bit when dealing with a head-of-tree model.
> 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
> Every 3.0.0-(label) release is effectively a major version in that case.
>
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
tomorrow in case there's more discussion. If any one is willing to help
review my script and JIRA queries, that'd also be great.
I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
be a very similar process.
Best,
Andrew
On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> > Does this mean you find our current system of listing a JIRA as being
> fixed in both a 2.6.x and 2.7.x to be confusing?
>
> Nope. I'm only confused when there isn't a .0 release in the fix
> line. When I see 2.6.x and 2.7.x I know that it was back ported to those
> branches. If I don't see a .0, I figure it's either a mistake or something
> that was already fixed by another change in that major/minor branch. It's
> almost always the former, however.
>
> > FWIW, my usecase is normally not "what is the earliest release that has
> this fix?" but rather "is this fix in this release?". If it's easy to query
> the latter, you can also determine the former. Some kind of query tool
> could help here.
>
> It literally becomes a grep if people commit the release data into
> the source tree, the release data is correct, etc:
>
> $ mvn install site -Preleasedocs -Pdocs -DskipTests
> $ grep issueid
> hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
>
> We should probably update the release process to make sure that
> *in progress* release data is also committed when a .0 is cut. That's
> likely missing. Another choice would be to modify the pom to that runs
> releasedocmaker to use a range rather than single version, but that gets a
> bit tricky with release dates, how big of a range, etc. Not impossible,
> just tricky. Probably needs to be script that gets run as part of
> create-release, maybe?
>
> (In reality, I do this grep against my git repo that generates the
> change log data automatically. This way it is always up-to-date and not
> dependent upon release data being committed. But that same grep could be
> done with a JQL query just as easily.)
>
> > For the release notes, am I correct in interpreting this as:
> >
> > * diff a.0.0 from the previous x.y.0 release
> > * diff a.b.0 from the previous a.0.0 or a.b.0 release
> > * diff a.b.c from the previous a.b.0 or a.b.c release
>
> Pretty much yes.
>
> > Ray pointed me at the changelogs of a few other enterprise software
> products, and this strategy seems pretty common. I like it.
>
> It's extremely common, to the point that putting every fix for
> every release touched is, at least to me, weird and extremely
> unconventional.
>
> > I realize now that this means a lot more JIRAs will need the 2.8.0 fix
> version, since they only have 2.6.x and 2.7.x.
>
> Yup.
>
> > This makes the fix rules actually pretty easy: the lowest a.b.0
> release and all non-.0 releases.
> >
> > I think this needs to be amended to handle the case of multiple major
> release branches, since we could have something committed for both 2.9.0
> and 3.1.0. So "lowest a.b.0 release within each major version"?
>
> Yeah, switching to effectively trunk-based development makes the
> rules harder. It's one of the reasons why the two big enterprisey
> companies I worked at prior to working on Hadoop didn't really do
> trunk-based for the vast majority of projects. They always cut a branch
> (or equivalent for that SCM) to delineate a break. Given the amount of
> ex-Sun folks involved in the early days of Hadoop, our pre-existing
> development processes very much reflect that culture.
>
> > This was true previously (no releases from trunk, trunk is versioned
> a.0.0), but now that trunk is essentially a minor release branch, its fix
> version needs to be treated as such.
>
> Yeah, I misspoke a bit when dealing with a head-of-tree model.
> 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
> Every 3.0.0-(label) release is effectively a major version in that case.
>
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
tomorrow in case there's more discussion. If any one is willing to help
review my script and JIRA queries, that'd also be great.
I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
be a very similar process.
Best,
Andrew
On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> > Does this mean you find our current system of listing a JIRA as being
> fixed in both a 2.6.x and 2.7.x to be confusing?
>
> Nope. I'm only confused when there isn't a .0 release in the fix
> line. When I see 2.6.x and 2.7.x I know that it was back ported to those
> branches. If I don't see a .0, I figure it's either a mistake or something
> that was already fixed by another change in that major/minor branch. It's
> almost always the former, however.
>
> > FWIW, my usecase is normally not "what is the earliest release that has
> this fix?" but rather "is this fix in this release?". If it's easy to query
> the latter, you can also determine the former. Some kind of query tool
> could help here.
>
> It literally becomes a grep if people commit the release data into
> the source tree, the release data is correct, etc:
>
> $ mvn install site -Preleasedocs -Pdocs -DskipTests
> $ grep issueid
> hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
>
> We should probably update the release process to make sure that
> *in progress* release data is also committed when a .0 is cut. That's
> likely missing. Another choice would be to modify the pom to that runs
> releasedocmaker to use a range rather than single version, but that gets a
> bit tricky with release dates, how big of a range, etc. Not impossible,
> just tricky. Probably needs to be script that gets run as part of
> create-release, maybe?
>
> (In reality, I do this grep against my git repo that generates the
> change log data automatically. This way it is always up-to-date and not
> dependent upon release data being committed. But that same grep could be
> done with a JQL query just as easily.)
>
> > For the release notes, am I correct in interpreting this as:
> >
> > * diff a.0.0 from the previous x.y.0 release
> > * diff a.b.0 from the previous a.0.0 or a.b.0 release
> > * diff a.b.c from the previous a.b.0 or a.b.c release
>
> Pretty much yes.
>
> > Ray pointed me at the changelogs of a few other enterprise software
> products, and this strategy seems pretty common. I like it.
>
> It's extremely common, to the point that putting every fix for
> every release touched is, at least to me, weird and extremely
> unconventional.
>
> > I realize now that this means a lot more JIRAs will need the 2.8.0 fix
> version, since they only have 2.6.x and 2.7.x.
>
> Yup.
>
> > This makes the fix rules actually pretty easy: the lowest a.b.0
> release and all non-.0 releases.
> >
> > I think this needs to be amended to handle the case of multiple major
> release branches, since we could have something committed for both 2.9.0
> and 3.1.0. So "lowest a.b.0 release within each major version"?
>
> Yeah, switching to effectively trunk-based development makes the
> rules harder. It's one of the reasons why the two big enterprisey
> companies I worked at prior to working on Hadoop didn't really do
> trunk-based for the vast majority of projects. They always cut a branch
> (or equivalent for that SCM) to delineate a break. Given the amount of
> ex-Sun folks involved in the early days of Hadoop, our pre-existing
> development processes very much reflect that culture.
>
> > This was true previously (no releases from trunk, trunk is versioned
> a.0.0), but now that trunk is essentially a minor release branch, its fix
> version needs to be treated as such.
>
> Yeah, I misspoke a bit when dealing with a head-of-tree model.
> 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
> Every 3.0.0-(label) release is effectively a major version in that case.
>
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com> wrote:
>
> Does this mean you find our current system of listing a JIRA as being fixed in both a 2.6.x and 2.7.x to be confusing?
Nope. I'm only confused when there isn't a .0 release in the fix line. When I see 2.6.x and 2.7.x I know that it was back ported to those branches. If I don't see a .0, I figure it's either a mistake or something that was already fixed by another change in that major/minor branch. It's almost always the former, however.
> FWIW, my usecase is normally not "what is the earliest release that has this fix?" but rather "is this fix in this release?". If it's easy to query the latter, you can also determine the former. Some kind of query tool could help here.
It literally becomes a grep if people commit the release data into the source tree, the release data is correct, etc:
$ mvn install site -Preleasedocs -Pdocs -DskipTests
$ grep issueid hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
We should probably update the release process to make sure that *in progress* release data is also committed when a .0 is cut. That's likely missing. Another choice would be to modify the pom to that runs releasedocmaker to use a range rather than single version, but that gets a bit tricky with release dates, how big of a range, etc. Not impossible, just tricky. Probably needs to be script that gets run as part of create-release, maybe?
(In reality, I do this grep against my git repo that generates the change log data automatically. This way it is always up-to-date and not dependent upon release data being committed. But that same grep could be done with a JQL query just as easily.)
> For the release notes, am I correct in interpreting this as:
>
> * diff a.0.0 from the previous x.y.0 release
> * diff a.b.0 from the previous a.0.0 or a.b.0 release
> * diff a.b.c from the previous a.b.0 or a.b.c release
Pretty much yes.
> Ray pointed me at the changelogs of a few other enterprise software products, and this strategy seems pretty common. I like it.
It's extremely common, to the point that putting every fix for every release touched is, at least to me, weird and extremely unconventional.
> I realize now that this means a lot more JIRAs will need the 2.8.0 fix version, since they only have 2.6.x and 2.7.x.
Yup.
> This makes the fix rules actually pretty easy: the lowest a.b.0 release and all non-.0 releases.
>
> I think this needs to be amended to handle the case of multiple major release branches, since we could have something committed for both 2.9.0 and 3.1.0. So "lowest a.b.0 release within each major version"?
Yeah, switching to effectively trunk-based development makes the rules harder. It's one of the reasons why the two big enterprisey companies I worked at prior to working on Hadoop didn't really do trunk-based for the vast majority of projects. They always cut a branch (or equivalent for that SCM) to delineate a break. Given the amount of ex-Sun folks involved in the early days of Hadoop, our pre-existing development processes very much reflect that culture.
> This was true previously (no releases from trunk, trunk is versioned a.0.0), but now that trunk is essentially a minor release branch, its fix version needs to be treated as such.
Yeah, I misspoke a bit when dealing with a head-of-tree model. 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously. Every 3.0.0-(label) release is effectively a major version in that case.
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com> wrote:
>
> Does this mean you find our current system of listing a JIRA as being fixed in both a 2.6.x and 2.7.x to be confusing?
Nope. I'm only confused when there isn't a .0 release in the fix line. When I see 2.6.x and 2.7.x I know that it was back ported to those branches. If I don't see a .0, I figure it's either a mistake or something that was already fixed by another change in that major/minor branch. It's almost always the former, however.
> FWIW, my usecase is normally not "what is the earliest release that has this fix?" but rather "is this fix in this release?". If it's easy to query the latter, you can also determine the former. Some kind of query tool could help here.
It literally becomes a grep if people commit the release data into the source tree, the release data is correct, etc:
$ mvn install site -Preleasedocs -Pdocs -DskipTests
$ grep issueid hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
We should probably update the release process to make sure that *in progress* release data is also committed when a .0 is cut. That's likely missing. Another choice would be to modify the pom to that runs releasedocmaker to use a range rather than single version, but that gets a bit tricky with release dates, how big of a range, etc. Not impossible, just tricky. Probably needs to be script that gets run as part of create-release, maybe?
(In reality, I do this grep against my git repo that generates the change log data automatically. This way it is always up-to-date and not dependent upon release data being committed. But that same grep could be done with a JQL query just as easily.)
> For the release notes, am I correct in interpreting this as:
>
> * diff a.0.0 from the previous x.y.0 release
> * diff a.b.0 from the previous a.0.0 or a.b.0 release
> * diff a.b.c from the previous a.b.0 or a.b.c release
Pretty much yes.
> Ray pointed me at the changelogs of a few other enterprise software products, and this strategy seems pretty common. I like it.
It's extremely common, to the point that putting every fix for every release touched is, at least to me, weird and extremely unconventional.
> I realize now that this means a lot more JIRAs will need the 2.8.0 fix version, since they only have 2.6.x and 2.7.x.
Yup.
> This makes the fix rules actually pretty easy: the lowest a.b.0 release and all non-.0 releases.
>
> I think this needs to be amended to handle the case of multiple major release branches, since we could have something committed for both 2.9.0 and 3.1.0. So "lowest a.b.0 release within each major version"?
Yeah, switching to effectively trunk-based development makes the rules harder. It's one of the reasons why the two big enterprisey companies I worked at prior to working on Hadoop didn't really do trunk-based for the vast majority of projects. They always cut a branch (or equivalent for that SCM) to delineate a break. Given the amount of ex-Sun folks involved in the early days of Hadoop, our pre-existing development processes very much reflect that culture.
> This was true previously (no releases from trunk, trunk is versioned a.0.0), but now that trunk is essentially a minor release branch, its fix version needs to be treated as such.
Yeah, I misspoke a bit when dealing with a head-of-tree model. 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously. Every 3.0.0-(label) release is effectively a major version in that case.
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jul 22, 2016, at 7:16 PM, Andrew Wang <an...@cloudera.com> wrote:
>
> Does this mean you find our current system of listing a JIRA as being fixed in both a 2.6.x and 2.7.x to be confusing?
Nope. I'm only confused when there isn't a .0 release in the fix line. When I see 2.6.x and 2.7.x I know that it was back ported to those branches. If I don't see a .0, I figure it's either a mistake or something that was already fixed by another change in that major/minor branch. It's almost always the former, however.
> FWIW, my usecase is normally not "what is the earliest release that has this fix?" but rather "is this fix in this release?". If it's easy to query the latter, you can also determine the former. Some kind of query tool could help here.
It literally becomes a grep if people commit the release data into the source tree, the release data is correct, etc:
$ mvn install site -Preleasedocs -Pdocs -DskipTests
$ grep issueid hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
We should probably update the release process to make sure that *in progress* release data is also committed when a .0 is cut. That's likely missing. Another choice would be to modify the pom to that runs releasedocmaker to use a range rather than single version, but that gets a bit tricky with release dates, how big of a range, etc. Not impossible, just tricky. Probably needs to be script that gets run as part of create-release, maybe?
(In reality, I do this grep against my git repo that generates the change log data automatically. This way it is always up-to-date and not dependent upon release data being committed. But that same grep could be done with a JQL query just as easily.)
> For the release notes, am I correct in interpreting this as:
>
> * diff a.0.0 from the previous x.y.0 release
> * diff a.b.0 from the previous a.0.0 or a.b.0 release
> * diff a.b.c from the previous a.b.0 or a.b.c release
Pretty much yes.
> Ray pointed me at the changelogs of a few other enterprise software products, and this strategy seems pretty common. I like it.
It's extremely common, to the point that putting every fix for every release touched is, at least to me, weird and extremely unconventional.
> I realize now that this means a lot more JIRAs will need the 2.8.0 fix version, since they only have 2.6.x and 2.7.x.
Yup.
> This makes the fix rules actually pretty easy: the lowest a.b.0 release and all non-.0 releases.
>
> I think this needs to be amended to handle the case of multiple major release branches, since we could have something committed for both 2.9.0 and 3.1.0. So "lowest a.b.0 release within each major version"?
Yeah, switching to effectively trunk-based development makes the rules harder. It's one of the reasons why the two big enterprisey companies I worked at prior to working on Hadoop didn't really do trunk-based for the vast majority of projects. They always cut a branch (or equivalent for that SCM) to delineate a break. Given the amount of ex-Sun folks involved in the early days of Hadoop, our pre-existing development processes very much reflect that culture.
> This was true previously (no releases from trunk, trunk is versioned a.0.0), but now that trunk is essentially a minor release branch, its fix version needs to be treated as such.
Yeah, I misspoke a bit when dealing with a head-of-tree model. 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously. Every 3.0.0-(label) release is effectively a major version in that case.
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Thanks for the input Allen, good perspective as always, inline:
> From the perspective of an end user who is reading multiple
> versions' listings at once, listing the same JIRA being fixed in multiple
> releases is totally confusing, especially now that release notes are
> actually readable. "So which version was it ACTUALLY fixed in?" is going
> to be the question. It'd be worthwhile for folks to actually build, say,
> trunk and look at the release notes section of the site build to see how
> these things are presented in aggregate before coming to any conclusions.
> Just viewing a single version's output will likely give a skewed
> perspective. (Or, I suppose you can read
> https://gitlab.com/_a__w_/eco-release-metadata/tree/master/HADOOP too,
> but the sort order is "wrong" for web viewing.)
>
> Does this mean you find our current system of listing a JIRA as being
fixed in both a 2.6.x and 2.7.x to be confusing?
FWIW, my usecase is normally not "what is the earliest release that has
this fix?" but rather "is this fix in this release?". If it's easy to query
the latter, you can also determine the former. Some kind of query tool
could help here.
> My read of the HowToCommit fix rules is that they were written
> from the perspective of how we typically use branches to cut releases. In
> other words, the changes and release notes for 2.6.x, where x>0, 2.7.y,
> where y>0, will likely not be fully present/complete in 2.8.0 so wouldn't
> actually reflect the entirety of, say, the 2.7.4 release if 2.7.4 and 2.8.0
> are being worked in parallel. This in turn means the changes and release
> notes become orthogonal once the minor release branch is cut. This is also
> important because there is no guarantee that a change made in, say, 2.7.4
> is actually in 2.8.0 because the code may have changed to the point that
> the fix isn't needed or wanted.
>
> From an automation perspective, I took the perspective that this
> means that the a.b.0 release notes are expected to be committed to all
> non-released major branches. So trunk will have release notes for 2.7.0,
> 2.8.0, 2.9.0, etc but not from 2.7.1, 2.8.1, or 2.9.1.
For the release notes, am I correct in interpreting this as:
* diff a.0.0 from the previous x.y.0 release
* diff a.b.0 from the previous a.0.0 or a.b.0 release
* diff a.b.c from the previous a.b.0 or a.b.c release
Ray pointed me at the changelogs of a few other enterprise software
products, and this strategy seems pretty common. I like it.
I realize now that this means a lot more JIRAs will need the 2.8.0 fix
version, since they only have 2.6.x and 2.7.x.
> This makes the fix rules actually pretty easy: the lowest a.b.0 release
> and all non-.0 releases.
I think this needs to be amended to handle the case of multiple major
release branches, since we could have something committed for both 2.9.0
and 3.1.0. So "lowest a.b.0 release within each major version"?
trunk, as always, is only listed if that is the only place where it was
> committed. (i.e., the lowest a.b.0 release happens to be the highest one
> available.)
>
This was true previously (no releases from trunk, trunk is versioned
a.0.0), but now that trunk is essentially a minor release branch, its fix
version needs to be treated as such.
> I suspect people are feeling confused or think the rules need to
> be changed...
>
The explanation here is far clearer than what's on HowToCommit,
particularly since the HowToCommit example branches are irrelevant in
today's era. If we like this versioning strategy, I'm happy to crib some of
this text and update the HowToCommit wiki.
In good news, my little python script to do bulk fixVersion updates seems
to work, so we can proceed posthaste once we have a plan.
Thanks,
Andrew
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Thanks for the input Allen, good perspective as always, inline:
> From the perspective of an end user who is reading multiple
> versions' listings at once, listing the same JIRA being fixed in multiple
> releases is totally confusing, especially now that release notes are
> actually readable. "So which version was it ACTUALLY fixed in?" is going
> to be the question. It'd be worthwhile for folks to actually build, say,
> trunk and look at the release notes section of the site build to see how
> these things are presented in aggregate before coming to any conclusions.
> Just viewing a single version's output will likely give a skewed
> perspective. (Or, I suppose you can read
> https://gitlab.com/_a__w_/eco-release-metadata/tree/master/HADOOP too,
> but the sort order is "wrong" for web viewing.)
>
> Does this mean you find our current system of listing a JIRA as being
fixed in both a 2.6.x and 2.7.x to be confusing?
FWIW, my usecase is normally not "what is the earliest release that has
this fix?" but rather "is this fix in this release?". If it's easy to query
the latter, you can also determine the former. Some kind of query tool
could help here.
> My read of the HowToCommit fix rules is that they were written
> from the perspective of how we typically use branches to cut releases. In
> other words, the changes and release notes for 2.6.x, where x>0, 2.7.y,
> where y>0, will likely not be fully present/complete in 2.8.0 so wouldn't
> actually reflect the entirety of, say, the 2.7.4 release if 2.7.4 and 2.8.0
> are being worked in parallel. This in turn means the changes and release
> notes become orthogonal once the minor release branch is cut. This is also
> important because there is no guarantee that a change made in, say, 2.7.4
> is actually in 2.8.0 because the code may have changed to the point that
> the fix isn't needed or wanted.
>
> From an automation perspective, I took the perspective that this
> means that the a.b.0 release notes are expected to be committed to all
> non-released major branches. So trunk will have release notes for 2.7.0,
> 2.8.0, 2.9.0, etc but not from 2.7.1, 2.8.1, or 2.9.1.
For the release notes, am I correct in interpreting this as:
* diff a.0.0 from the previous x.y.0 release
* diff a.b.0 from the previous a.0.0 or a.b.0 release
* diff a.b.c from the previous a.b.0 or a.b.c release
Ray pointed me at the changelogs of a few other enterprise software
products, and this strategy seems pretty common. I like it.
I realize now that this means a lot more JIRAs will need the 2.8.0 fix
version, since they only have 2.6.x and 2.7.x.
> This makes the fix rules actually pretty easy: the lowest a.b.0 release
> and all non-.0 releases.
I think this needs to be amended to handle the case of multiple major
release branches, since we could have something committed for both 2.9.0
and 3.1.0. So "lowest a.b.0 release within each major version"?
trunk, as always, is only listed if that is the only place where it was
> committed. (i.e., the lowest a.b.0 release happens to be the highest one
> available.)
>
This was true previously (no releases from trunk, trunk is versioned
a.0.0), but now that trunk is essentially a minor release branch, its fix
version needs to be treated as such.
> I suspect people are feeling confused or think the rules need to
> be changed...
>
The explanation here is far clearer than what's on HowToCommit,
particularly since the HowToCommit example branches are irrelevant in
today's era. If we like this versioning strategy, I'm happy to crib some of
this text and update the HowToCommit wiki.
In good news, my little python script to do bulk fixVersion updates seems
to work, so we can proceed posthaste once we have a plan.
Thanks,
Andrew
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Thanks for the input Allen, good perspective as always, inline:
> From the perspective of an end user who is reading multiple
> versions' listings at once, listing the same JIRA being fixed in multiple
> releases is totally confusing, especially now that release notes are
> actually readable. "So which version was it ACTUALLY fixed in?" is going
> to be the question. It'd be worthwhile for folks to actually build, say,
> trunk and look at the release notes section of the site build to see how
> these things are presented in aggregate before coming to any conclusions.
> Just viewing a single version's output will likely give a skewed
> perspective. (Or, I suppose you can read
> https://gitlab.com/_a__w_/eco-release-metadata/tree/master/HADOOP too,
> but the sort order is "wrong" for web viewing.)
>
> Does this mean you find our current system of listing a JIRA as being
fixed in both a 2.6.x and 2.7.x to be confusing?
FWIW, my usecase is normally not "what is the earliest release that has
this fix?" but rather "is this fix in this release?". If it's easy to query
the latter, you can also determine the former. Some kind of query tool
could help here.
> My read of the HowToCommit fix rules is that they were written
> from the perspective of how we typically use branches to cut releases. In
> other words, the changes and release notes for 2.6.x, where x>0, 2.7.y,
> where y>0, will likely not be fully present/complete in 2.8.0 so wouldn't
> actually reflect the entirety of, say, the 2.7.4 release if 2.7.4 and 2.8.0
> are being worked in parallel. This in turn means the changes and release
> notes become orthogonal once the minor release branch is cut. This is also
> important because there is no guarantee that a change made in, say, 2.7.4
> is actually in 2.8.0 because the code may have changed to the point that
> the fix isn't needed or wanted.
>
> From an automation perspective, I took the perspective that this
> means that the a.b.0 release notes are expected to be committed to all
> non-released major branches. So trunk will have release notes for 2.7.0,
> 2.8.0, 2.9.0, etc but not from 2.7.1, 2.8.1, or 2.9.1.
For the release notes, am I correct in interpreting this as:
* diff a.0.0 from the previous x.y.0 release
* diff a.b.0 from the previous a.0.0 or a.b.0 release
* diff a.b.c from the previous a.b.0 or a.b.c release
Ray pointed me at the changelogs of a few other enterprise software
products, and this strategy seems pretty common. I like it.
I realize now that this means a lot more JIRAs will need the 2.8.0 fix
version, since they only have 2.6.x and 2.7.x.
> This makes the fix rules actually pretty easy: the lowest a.b.0 release
> and all non-.0 releases.
I think this needs to be amended to handle the case of multiple major
release branches, since we could have something committed for both 2.9.0
and 3.1.0. So "lowest a.b.0 release within each major version"?
trunk, as always, is only listed if that is the only place where it was
> committed. (i.e., the lowest a.b.0 release happens to be the highest one
> available.)
>
This was true previously (no releases from trunk, trunk is versioned
a.0.0), but now that trunk is essentially a minor release branch, its fix
version needs to be treated as such.
> I suspect people are feeling confused or think the rules need to
> be changed...
>
The explanation here is far clearer than what's on HowToCommit,
particularly since the HowToCommit example branches are irrelevant in
today's era. If we like this versioning strategy, I'm happy to crib some of
this text and update the HowToCommit wiki.
In good news, my little python script to do bulk fixVersion updates seems
to work, so we can proceed posthaste once we have a plan.
Thanks,
Andrew
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
From the perspective of an end user who is reading multiple versions' listings at once, listing the same JIRA being fixed in multiple releases is totally confusing, especially now that release notes are actually readable. "So which version was it ACTUALLY fixed in?" is going to be the question. It'd be worthwhile for folks to actually build, say, trunk and look at the release notes section of the site build to see how these things are presented in aggregate before coming to any conclusions. Just viewing a single version's output will likely give a skewed perspective. (Or, I suppose you can read https://gitlab.com/_a__w_/eco-release-metadata/tree/master/HADOOP too, but the sort order is "wrong" for web viewing.)
My read of the HowToCommit fix rules is that they were written from the perspective of how we typically use branches to cut releases. In other words, the changes and release notes for 2.6.x, where x>0, 2.7.y, where y>0, will likely not be fully present/complete in 2.8.0 so wouldn't actually reflect the entirety of, say, the 2.7.4 release if 2.7.4 and 2.8.0 are being worked in parallel. This in turn means the changes and release notes become orthogonal once the minor release branch is cut. This is also important because there is no guarantee that a change made in, say, 2.7.4 is actually in 2.8.0 because the code may have changed to the point that the fix isn't needed or wanted.
From an automation perspective, I took the perspective that this means that the a.b.0 release notes are expected to be committed to all non-released major branches. So trunk will have release notes for 2.7.0, 2.8.0, 2.9.0, etc but not from 2.7.1, 2.8.1, or 2.9.1. This makes the fix rules actually pretty easy: the lowest a.b.0 release and all non-.0 releases. trunk, as always, is only listed if that is the only place where it was committed. (i.e., the lowest a.b.0 release happens to be the highest one available.)
I suspect people are feeling confused or think the rules need to be changed mainly because a) we have a lot more branches getting RE work than ever before in Hadoop's history and b) 2.8.0 has been hanging out in an unreleased branch for ~7 months. [The PMC should probably vote to kill that branch and just cut a new 2.8.0 based off of the current top of branch-2. I think that'd go a long way to clearing the confusion as well as actually making 2.8.0 relevant again for those that still want to work on branch-2.]
Also:
> Assuming the semantic versioning (http://semver.org) as
> our baseline thinking,
We don't use semantic versioning and you'll find zero references to it in any Apache Hadoop documentation. If we were following semver, even in the loosest sense, 2.7.0 should have been 3.0.0 with the JRE upgrade requirement. (which, ironically, is still causing issues with folks moving things between 2.6 and 2.7+, see the other thread about the Dockerfile.) In a stricter sense, we should be on v11 or something, given the amount of incompatible changes throughout branch-2's history.
> On Jul 22, 2016, at 11:44 AM, Andrew Wang <an...@cloudera.com> wrote:
>
>>
>>
>>> I am also not quite sure I understand the rationale of what's in the
>> HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as
>> our baseline thinking, having concurrent release streams alone breaks the
>> principle. And that is *regardless of* how we line up individual releases
>> in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where *
>> is any number. Therefore, the moment we have any new 2.6.z release after
>> 2.7.0, the rule is broken and remains that way. Timing of subsequent
>> releases is somewhat irrelevant.
>>
>> From a practical standpoint, I would love to know whether a certain patch
>> has been backported to a specific version. Thus, I would love to see fix
>> version enumerating all the releases that the JIRA went into. Basically the
>> more disclosure, the better. That would also make it easier for us
>> committers to see the state of the porting and identify issues like being
>> ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our
>> policy?
>>
>>
> I also err towards more fix versions. Based on our branching strategy of
> branch-x -> branch-x.y -> branch->x.y.z, I think this means that the
> changelog will identify everything since the previous
> last-version-component of the branch name. So 2.6.5 diffs against 2.6.4,
> 2.8.0 diffs against 2.7.0, 3.0.0 against 2.0.0. This makes it more
> straightforward for users to determine what changelogs are important, based
> purely on the version number.
>
> I agree with Sangjin that the #1 question that the changelogs should
> address is whether a certain patch is present in a version. For this
> usecase, it's better to have duplicate info than to omit something.
>
> To answer "what's new", I think that's answered by the manually curated
> release notes, like the ones we put together at HADOOP-13383.
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
From the perspective of an end user who is reading multiple versions' listings at once, listing the same JIRA being fixed in multiple releases is totally confusing, especially now that release notes are actually readable. "So which version was it ACTUALLY fixed in?" is going to be the question. It'd be worthwhile for folks to actually build, say, trunk and look at the release notes section of the site build to see how these things are presented in aggregate before coming to any conclusions. Just viewing a single version's output will likely give a skewed perspective. (Or, I suppose you can read https://gitlab.com/_a__w_/eco-release-metadata/tree/master/HADOOP too, but the sort order is "wrong" for web viewing.)
My read of the HowToCommit fix rules is that they were written from the perspective of how we typically use branches to cut releases. In other words, the changes and release notes for 2.6.x, where x>0, 2.7.y, where y>0, will likely not be fully present/complete in 2.8.0 so wouldn't actually reflect the entirety of, say, the 2.7.4 release if 2.7.4 and 2.8.0 are being worked in parallel. This in turn means the changes and release notes become orthogonal once the minor release branch is cut. This is also important because there is no guarantee that a change made in, say, 2.7.4 is actually in 2.8.0 because the code may have changed to the point that the fix isn't needed or wanted.
From an automation perspective, I took the perspective that this means that the a.b.0 release notes are expected to be committed to all non-released major branches. So trunk will have release notes for 2.7.0, 2.8.0, 2.9.0, etc but not from 2.7.1, 2.8.1, or 2.9.1. This makes the fix rules actually pretty easy: the lowest a.b.0 release and all non-.0 releases. trunk, as always, is only listed if that is the only place where it was committed. (i.e., the lowest a.b.0 release happens to be the highest one available.)
I suspect people are feeling confused or think the rules need to be changed mainly because a) we have a lot more branches getting RE work than ever before in Hadoop's history and b) 2.8.0 has been hanging out in an unreleased branch for ~7 months. [The PMC should probably vote to kill that branch and just cut a new 2.8.0 based off of the current top of branch-2. I think that'd go a long way to clearing the confusion as well as actually making 2.8.0 relevant again for those that still want to work on branch-2.]
Also:
> Assuming the semantic versioning (http://semver.org) as
> our baseline thinking,
We don't use semantic versioning and you'll find zero references to it in any Apache Hadoop documentation. If we were following semver, even in the loosest sense, 2.7.0 should have been 3.0.0 with the JRE upgrade requirement. (which, ironically, is still causing issues with folks moving things between 2.6 and 2.7+, see the other thread about the Dockerfile.) In a stricter sense, we should be on v11 or something, given the amount of incompatible changes throughout branch-2's history.
> On Jul 22, 2016, at 11:44 AM, Andrew Wang <an...@cloudera.com> wrote:
>
>>
>>
>>> I am also not quite sure I understand the rationale of what's in the
>> HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as
>> our baseline thinking, having concurrent release streams alone breaks the
>> principle. And that is *regardless of* how we line up individual releases
>> in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where *
>> is any number. Therefore, the moment we have any new 2.6.z release after
>> 2.7.0, the rule is broken and remains that way. Timing of subsequent
>> releases is somewhat irrelevant.
>>
>> From a practical standpoint, I would love to know whether a certain patch
>> has been backported to a specific version. Thus, I would love to see fix
>> version enumerating all the releases that the JIRA went into. Basically the
>> more disclosure, the better. That would also make it easier for us
>> committers to see the state of the porting and identify issues like being
>> ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our
>> policy?
>>
>>
> I also err towards more fix versions. Based on our branching strategy of
> branch-x -> branch-x.y -> branch->x.y.z, I think this means that the
> changelog will identify everything since the previous
> last-version-component of the branch name. So 2.6.5 diffs against 2.6.4,
> 2.8.0 diffs against 2.7.0, 3.0.0 against 2.0.0. This makes it more
> straightforward for users to determine what changelogs are important, based
> purely on the version number.
>
> I agree with Sangjin that the #1 question that the changelogs should
> address is whether a certain patch is present in a version. For this
> usecase, it's better to have duplicate info than to omit something.
>
> To answer "what's new", I think that's answered by the manually curated
> release notes, like the ones we put together at HADOOP-13383.
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
From the perspective of an end user who is reading multiple versions' listings at once, listing the same JIRA being fixed in multiple releases is totally confusing, especially now that release notes are actually readable. "So which version was it ACTUALLY fixed in?" is going to be the question. It'd be worthwhile for folks to actually build, say, trunk and look at the release notes section of the site build to see how these things are presented in aggregate before coming to any conclusions. Just viewing a single version's output will likely give a skewed perspective. (Or, I suppose you can read https://gitlab.com/_a__w_/eco-release-metadata/tree/master/HADOOP too, but the sort order is "wrong" for web viewing.)
My read of the HowToCommit fix rules is that they were written from the perspective of how we typically use branches to cut releases. In other words, the changes and release notes for 2.6.x, where x>0, 2.7.y, where y>0, will likely not be fully present/complete in 2.8.0 so wouldn't actually reflect the entirety of, say, the 2.7.4 release if 2.7.4 and 2.8.0 are being worked in parallel. This in turn means the changes and release notes become orthogonal once the minor release branch is cut. This is also important because there is no guarantee that a change made in, say, 2.7.4 is actually in 2.8.0 because the code may have changed to the point that the fix isn't needed or wanted.
From an automation perspective, I took the perspective that this means that the a.b.0 release notes are expected to be committed to all non-released major branches. So trunk will have release notes for 2.7.0, 2.8.0, 2.9.0, etc but not from 2.7.1, 2.8.1, or 2.9.1. This makes the fix rules actually pretty easy: the lowest a.b.0 release and all non-.0 releases. trunk, as always, is only listed if that is the only place where it was committed. (i.e., the lowest a.b.0 release happens to be the highest one available.)
I suspect people are feeling confused or think the rules need to be changed mainly because a) we have a lot more branches getting RE work than ever before in Hadoop's history and b) 2.8.0 has been hanging out in an unreleased branch for ~7 months. [The PMC should probably vote to kill that branch and just cut a new 2.8.0 based off of the current top of branch-2. I think that'd go a long way to clearing the confusion as well as actually making 2.8.0 relevant again for those that still want to work on branch-2.]
Also:
> Assuming the semantic versioning (http://semver.org) as
> our baseline thinking,
We don't use semantic versioning and you'll find zero references to it in any Apache Hadoop documentation. If we were following semver, even in the loosest sense, 2.7.0 should have been 3.0.0 with the JRE upgrade requirement. (which, ironically, is still causing issues with folks moving things between 2.6 and 2.7+, see the other thread about the Dockerfile.) In a stricter sense, we should be on v11 or something, given the amount of incompatible changes throughout branch-2's history.
> On Jul 22, 2016, at 11:44 AM, Andrew Wang <an...@cloudera.com> wrote:
>
>>
>>
>>> I am also not quite sure I understand the rationale of what's in the
>> HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as
>> our baseline thinking, having concurrent release streams alone breaks the
>> principle. And that is *regardless of* how we line up individual releases
>> in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where *
>> is any number. Therefore, the moment we have any new 2.6.z release after
>> 2.7.0, the rule is broken and remains that way. Timing of subsequent
>> releases is somewhat irrelevant.
>>
>> From a practical standpoint, I would love to know whether a certain patch
>> has been backported to a specific version. Thus, I would love to see fix
>> version enumerating all the releases that the JIRA went into. Basically the
>> more disclosure, the better. That would also make it easier for us
>> committers to see the state of the porting and identify issues like being
>> ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our
>> policy?
>>
>>
> I also err towards more fix versions. Based on our branching strategy of
> branch-x -> branch-x.y -> branch->x.y.z, I think this means that the
> changelog will identify everything since the previous
> last-version-component of the branch name. So 2.6.5 diffs against 2.6.4,
> 2.8.0 diffs against 2.7.0, 3.0.0 against 2.0.0. This makes it more
> straightforward for users to determine what changelogs are important, based
> purely on the version number.
>
> I agree with Sangjin that the #1 question that the changelogs should
> address is whether a certain patch is present in a version. For this
> usecase, it's better to have duplicate info than to omit something.
>
> To answer "what's new", I think that's answered by the manually curated
> release notes, like the ones we put together at HADOOP-13383.
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
>
>
>> I am also not quite sure I understand the rationale of what's in the
> HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as
> our baseline thinking, having concurrent release streams alone breaks the
> principle. And that is *regardless of* how we line up individual releases
> in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where *
> is any number. Therefore, the moment we have any new 2.6.z release after
> 2.7.0, the rule is broken and remains that way. Timing of subsequent
> releases is somewhat irrelevant.
>
> From a practical standpoint, I would love to know whether a certain patch
> has been backported to a specific version. Thus, I would love to see fix
> version enumerating all the releases that the JIRA went into. Basically the
> more disclosure, the better. That would also make it easier for us
> committers to see the state of the porting and identify issues like being
> ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our
> policy?
>
>
I also err towards more fix versions. Based on our branching strategy of
branch-x -> branch-x.y -> branch->x.y.z, I think this means that the
changelog will identify everything since the previous
last-version-component of the branch name. So 2.6.5 diffs against 2.6.4,
2.8.0 diffs against 2.7.0, 3.0.0 against 2.0.0. This makes it more
straightforward for users to determine what changelogs are important, based
purely on the version number.
I agree with Sangjin that the #1 question that the changelogs should
address is whether a certain patch is present in a version. For this
usecase, it's better to have duplicate info than to omit something.
To answer "what's new", I think that's answered by the manually curated
release notes, like the ones we put together at HADOOP-13383.
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
>
>
>> I am also not quite sure I understand the rationale of what's in the
> HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as
> our baseline thinking, having concurrent release streams alone breaks the
> principle. And that is *regardless of* how we line up individual releases
> in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where *
> is any number. Therefore, the moment we have any new 2.6.z release after
> 2.7.0, the rule is broken and remains that way. Timing of subsequent
> releases is somewhat irrelevant.
>
> From a practical standpoint, I would love to know whether a certain patch
> has been backported to a specific version. Thus, I would love to see fix
> version enumerating all the releases that the JIRA went into. Basically the
> more disclosure, the better. That would also make it easier for us
> committers to see the state of the porting and identify issues like being
> ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our
> policy?
>
>
I also err towards more fix versions. Based on our branching strategy of
branch-x -> branch-x.y -> branch->x.y.z, I think this means that the
changelog will identify everything since the previous
last-version-component of the branch name. So 2.6.5 diffs against 2.6.4,
2.8.0 diffs against 2.7.0, 3.0.0 against 2.0.0. This makes it more
straightforward for users to determine what changelogs are important, based
purely on the version number.
I agree with Sangjin that the #1 question that the changelogs should
address is whether a certain patch is present in a version. For this
usecase, it's better to have duplicate info than to omit something.
To answer "what's new", I think that's answered by the manually curated
release notes, like the ones we put together at HADOOP-13383.
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
>
>
>> I am also not quite sure I understand the rationale of what's in the
> HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as
> our baseline thinking, having concurrent release streams alone breaks the
> principle. And that is *regardless of* how we line up individual releases
> in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where *
> is any number. Therefore, the moment we have any new 2.6.z release after
> 2.7.0, the rule is broken and remains that way. Timing of subsequent
> releases is somewhat irrelevant.
>
> From a practical standpoint, I would love to know whether a certain patch
> has been backported to a specific version. Thus, I would love to see fix
> version enumerating all the releases that the JIRA went into. Basically the
> more disclosure, the better. That would also make it easier for us
> committers to see the state of the porting and identify issues like being
> ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our
> policy?
>
>
I also err towards more fix versions. Based on our branching strategy of
branch-x -> branch-x.y -> branch->x.y.z, I think this means that the
changelog will identify everything since the previous
last-version-component of the branch name. So 2.6.5 diffs against 2.6.4,
2.8.0 diffs against 2.7.0, 3.0.0 against 2.0.0. This makes it more
straightforward for users to determine what changelogs are important, based
purely on the version number.
I agree with Sangjin that the #1 question that the changelogs should
address is whether a certain patch is present in a version. For this
usecase, it's better to have duplicate info than to omit something.
To answer "what's new", I think that's answered by the manually curated
release notes, like the ones we put together at HADOOP-13383.
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sangjin Lee <sj...@apache.org>.
On Thu, Jul 21, 2016 at 3:58 PM, Andrew Wang <an...@cloudera.com>
wrote:
> Thanks for the input Vinod, inline:
>
>
> > Similarly the list of features we are enabling in this alpha would be
> good
> > - may be update the Roadmap wiki. Things like classpath-isolation which
> > were part of the original 3.x roadmap are still not done.
> >
> > I already updated the website release notes at HADOOP-13383. I can update
> the Roadmap wiki and break out what's new in alpha1 too, thanks for the
> reminder.
>
>
> > > * Community bandwidth isn't zero-sum. This particularly applies to
> > people working on features that are only present in trunk, like EC, shell
> > script rewrite, etc.
> >
> >
> > A bunch of us are going to be busy with finishing 2.8.0. It isn’t
> > zero-sum, but it predicates those of us involved with 2.8.0 from looking
> at
> > it, even though we are very interested in doing so.
> >
> > There's a plan for more 3.0.0 alphas, so there's still time to help out
> before things settle down for beta. If 2.8.0 is ready to go, it should
> happen before even alpha2.
>
> >
> > Obviously, I am not making the case that this issue won’t happen ever. In
> > fact, this already happened with the parallel 2.6.x and 2.7.x releases.
> And
> > we precisely avoided major confusion there by lining up 2.7.2 behind
> 2.6.3
> > etc.
> >
>
> Could you clarify how lining up releases differently avoids the fix version
> issue?
>
> What we've been doing is something like "one fix version per active release
> line". Since we've revived 3.x as a release line, it seems like a lot of
> JIRAs need 3.x fix versions now.
>
> As an aside, I honestly don't know how to interpret the fix version
> instructions on the HowToCommit wiki. They don't seem to match up with what
> we actually do in practice.
>
I am also not quite sure I understand the rationale of what's in the
HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as
our baseline thinking, having concurrent release streams alone breaks the
principle. And that is *regardless of* how we line up individual releases
in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where *
is any number. Therefore, the moment we have any new 2.6.z release after
2.7.0, the rule is broken and remains that way. Timing of subsequent
releases is somewhat irrelevant.
From a practical standpoint, I would love to know whether a certain patch
has been backported to a specific version. Thus, I would love to see fix
version enumerating all the releases that the JIRA went into. Basically the
more disclosure, the better. That would also make it easier for us
committers to see the state of the porting and identify issues like being
ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our
policy?
>
> Best,
> Andrew
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
>> There's a plan for more 3.0.0 alphas, so there's still time to help out
> before things settle down for beta. If 2.8.0 is ready to go, it should
> happen before even alpha2.
I wasn’t talk about my irresistible urge to help (which of course is there : )) , it was about making sure enough eye-balls look through this. If it absolutely cannot wait (which I don’t still understand why), we will just have to do double-shifts I guess.
>>
>> Obviously, I am not making the case that this issue won’t happen ever. In
>> fact, this already happened with the parallel 2.6.x and 2.7.x releases. And
>> we precisely avoided major confusion there by lining up 2.7.2 behind 2.6.3
>> etc.
>>
>
> Could you clarify how lining up releases differently avoids the fix version
> issue?
It wouldn’t avoid the issue, it reduces it by quite a bit.
The versioning discussion happened a lot of times before and we never got to semantic versioning or any such convention. If it helps, we can revive the discussion. So far, all the releases have documented as the change-list only the issues “that are not in the last release, date-wise, whether in this major number or the ones below”. It is a simple timeline ordering, and it worked okay with two concurrent releases. So, if 2.8.0 happens before 3.0.0-alpha1, the additional changes that make the change-list for 3.0.0-alpha1 will be a delta of trunk-only changes.
Again, lining up releses doesn’t fix the core issue of running parallel (>2) releases - it just continues the current order of things. For now, the only tool we have is timeline ordering of 2 releases. The typical question from anyone is “which version did this get fixed in” and the answer is always found from JIRA + svn/git-log. And the fact that the (>2) concurrent releases is a new ground for this community (yes, you are hearing it right, this didn’t ever happen before for an extended period of time), we need to make some new rules before we make more of these releases and make it harder to follow for everyone.
Thanks
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sangjin Lee <sj...@apache.org>.
On Thu, Jul 21, 2016 at 3:58 PM, Andrew Wang <an...@cloudera.com>
wrote:
> Thanks for the input Vinod, inline:
>
>
> > Similarly the list of features we are enabling in this alpha would be
> good
> > - may be update the Roadmap wiki. Things like classpath-isolation which
> > were part of the original 3.x roadmap are still not done.
> >
> > I already updated the website release notes at HADOOP-13383. I can update
> the Roadmap wiki and break out what's new in alpha1 too, thanks for the
> reminder.
>
>
> > > * Community bandwidth isn't zero-sum. This particularly applies to
> > people working on features that are only present in trunk, like EC, shell
> > script rewrite, etc.
> >
> >
> > A bunch of us are going to be busy with finishing 2.8.0. It isn’t
> > zero-sum, but it predicates those of us involved with 2.8.0 from looking
> at
> > it, even though we are very interested in doing so.
> >
> > There's a plan for more 3.0.0 alphas, so there's still time to help out
> before things settle down for beta. If 2.8.0 is ready to go, it should
> happen before even alpha2.
>
> >
> > Obviously, I am not making the case that this issue won’t happen ever. In
> > fact, this already happened with the parallel 2.6.x and 2.7.x releases.
> And
> > we precisely avoided major confusion there by lining up 2.7.2 behind
> 2.6.3
> > etc.
> >
>
> Could you clarify how lining up releases differently avoids the fix version
> issue?
>
> What we've been doing is something like "one fix version per active release
> line". Since we've revived 3.x as a release line, it seems like a lot of
> JIRAs need 3.x fix versions now.
>
> As an aside, I honestly don't know how to interpret the fix version
> instructions on the HowToCommit wiki. They don't seem to match up with what
> we actually do in practice.
>
I am also not quite sure I understand the rationale of what's in the
HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as
our baseline thinking, having concurrent release streams alone breaks the
principle. And that is *regardless of* how we line up individual releases
in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where *
is any number. Therefore, the moment we have any new 2.6.z release after
2.7.0, the rule is broken and remains that way. Timing of subsequent
releases is somewhat irrelevant.
From a practical standpoint, I would love to know whether a certain patch
has been backported to a specific version. Thus, I would love to see fix
version enumerating all the releases that the JIRA went into. Basically the
more disclosure, the better. That would also make it easier for us
committers to see the state of the porting and identify issues like being
ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our
policy?
>
> Best,
> Andrew
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
>> There's a plan for more 3.0.0 alphas, so there's still time to help out
> before things settle down for beta. If 2.8.0 is ready to go, it should
> happen before even alpha2.
I wasn’t talk about my irresistible urge to help (which of course is there : )) , it was about making sure enough eye-balls look through this. If it absolutely cannot wait (which I don’t still understand why), we will just have to do double-shifts I guess.
>>
>> Obviously, I am not making the case that this issue won’t happen ever. In
>> fact, this already happened with the parallel 2.6.x and 2.7.x releases. And
>> we precisely avoided major confusion there by lining up 2.7.2 behind 2.6.3
>> etc.
>>
>
> Could you clarify how lining up releases differently avoids the fix version
> issue?
It wouldn’t avoid the issue, it reduces it by quite a bit.
The versioning discussion happened a lot of times before and we never got to semantic versioning or any such convention. If it helps, we can revive the discussion. So far, all the releases have documented as the change-list only the issues “that are not in the last release, date-wise, whether in this major number or the ones below”. It is a simple timeline ordering, and it worked okay with two concurrent releases. So, if 2.8.0 happens before 3.0.0-alpha1, the additional changes that make the change-list for 3.0.0-alpha1 will be a delta of trunk-only changes.
Again, lining up releses doesn’t fix the core issue of running parallel (>2) releases - it just continues the current order of things. For now, the only tool we have is timeline ordering of 2 releases. The typical question from anyone is “which version did this get fixed in” and the answer is always found from JIRA + svn/git-log. And the fact that the (>2) concurrent releases is a new ground for this community (yes, you are hearing it right, this didn’t ever happen before for an extended period of time), we need to make some new rules before we make more of these releases and make it harder to follow for everyone.
Thanks
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
>> There's a plan for more 3.0.0 alphas, so there's still time to help out
> before things settle down for beta. If 2.8.0 is ready to go, it should
> happen before even alpha2.
I wasn’t talk about my irresistible urge to help (which of course is there : )) , it was about making sure enough eye-balls look through this. If it absolutely cannot wait (which I don’t still understand why), we will just have to do double-shifts I guess.
>>
>> Obviously, I am not making the case that this issue won’t happen ever. In
>> fact, this already happened with the parallel 2.6.x and 2.7.x releases. And
>> we precisely avoided major confusion there by lining up 2.7.2 behind 2.6.3
>> etc.
>>
>
> Could you clarify how lining up releases differently avoids the fix version
> issue?
It wouldn’t avoid the issue, it reduces it by quite a bit.
The versioning discussion happened a lot of times before and we never got to semantic versioning or any such convention. If it helps, we can revive the discussion. So far, all the releases have documented as the change-list only the issues “that are not in the last release, date-wise, whether in this major number or the ones below”. It is a simple timeline ordering, and it worked okay with two concurrent releases. So, if 2.8.0 happens before 3.0.0-alpha1, the additional changes that make the change-list for 3.0.0-alpha1 will be a delta of trunk-only changes.
Again, lining up releses doesn’t fix the core issue of running parallel (>2) releases - it just continues the current order of things. For now, the only tool we have is timeline ordering of 2 releases. The typical question from anyone is “which version did this get fixed in” and the answer is always found from JIRA + svn/git-log. And the fact that the (>2) concurrent releases is a new ground for this community (yes, you are hearing it right, this didn’t ever happen before for an extended period of time), we need to make some new rules before we make more of these releases and make it harder to follow for everyone.
Thanks
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sangjin Lee <sj...@apache.org>.
On Thu, Jul 21, 2016 at 3:58 PM, Andrew Wang <an...@cloudera.com>
wrote:
> Thanks for the input Vinod, inline:
>
>
> > Similarly the list of features we are enabling in this alpha would be
> good
> > - may be update the Roadmap wiki. Things like classpath-isolation which
> > were part of the original 3.x roadmap are still not done.
> >
> > I already updated the website release notes at HADOOP-13383. I can update
> the Roadmap wiki and break out what's new in alpha1 too, thanks for the
> reminder.
>
>
> > > * Community bandwidth isn't zero-sum. This particularly applies to
> > people working on features that are only present in trunk, like EC, shell
> > script rewrite, etc.
> >
> >
> > A bunch of us are going to be busy with finishing 2.8.0. It isn’t
> > zero-sum, but it predicates those of us involved with 2.8.0 from looking
> at
> > it, even though we are very interested in doing so.
> >
> > There's a plan for more 3.0.0 alphas, so there's still time to help out
> before things settle down for beta. If 2.8.0 is ready to go, it should
> happen before even alpha2.
>
> >
> > Obviously, I am not making the case that this issue won’t happen ever. In
> > fact, this already happened with the parallel 2.6.x and 2.7.x releases.
> And
> > we precisely avoided major confusion there by lining up 2.7.2 behind
> 2.6.3
> > etc.
> >
>
> Could you clarify how lining up releases differently avoids the fix version
> issue?
>
> What we've been doing is something like "one fix version per active release
> line". Since we've revived 3.x as a release line, it seems like a lot of
> JIRAs need 3.x fix versions now.
>
> As an aside, I honestly don't know how to interpret the fix version
> instructions on the HowToCommit wiki. They don't seem to match up with what
> we actually do in practice.
>
I am also not quite sure I understand the rationale of what's in the
HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as
our baseline thinking, having concurrent release streams alone breaks the
principle. And that is *regardless of* how we line up individual releases
in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where *
is any number. Therefore, the moment we have any new 2.6.z release after
2.7.0, the rule is broken and remains that way. Timing of subsequent
releases is somewhat irrelevant.
From a practical standpoint, I would love to know whether a certain patch
has been backported to a specific version. Thus, I would love to see fix
version enumerating all the releases that the JIRA went into. Basically the
more disclosure, the better. That would also make it easier for us
committers to see the state of the porting and identify issues like being
ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our
policy?
>
> Best,
> Andrew
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Thanks for the input Vinod, inline:
> Similarly the list of features we are enabling in this alpha would be good
> - may be update the Roadmap wiki. Things like classpath-isolation which
> were part of the original 3.x roadmap are still not done.
>
> I already updated the website release notes at HADOOP-13383. I can update
the Roadmap wiki and break out what's new in alpha1 too, thanks for the
reminder.
> > * Community bandwidth isn't zero-sum. This particularly applies to
> people working on features that are only present in trunk, like EC, shell
> script rewrite, etc.
>
>
> A bunch of us are going to be busy with finishing 2.8.0. It isn’t
> zero-sum, but it predicates those of us involved with 2.8.0 from looking at
> it, even though we are very interested in doing so.
>
> There's a plan for more 3.0.0 alphas, so there's still time to help out
before things settle down for beta. If 2.8.0 is ready to go, it should
happen before even alpha2.
>
> Obviously, I am not making the case that this issue won’t happen ever. In
> fact, this already happened with the parallel 2.6.x and 2.7.x releases. And
> we precisely avoided major confusion there by lining up 2.7.2 behind 2.6.3
> etc.
>
Could you clarify how lining up releases differently avoids the fix version
issue?
What we've been doing is something like "one fix version per active release
line". Since we've revived 3.x as a release line, it seems like a lot of
JIRAs need 3.x fix versions now.
As an aside, I honestly don't know how to interpret the fix version
instructions on the HowToCommit wiki. They don't seem to match up with what
we actually do in practice.
Best,
Andrew
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Thanks for the input Vinod, inline:
> Similarly the list of features we are enabling in this alpha would be good
> - may be update the Roadmap wiki. Things like classpath-isolation which
> were part of the original 3.x roadmap are still not done.
>
> I already updated the website release notes at HADOOP-13383. I can update
the Roadmap wiki and break out what's new in alpha1 too, thanks for the
reminder.
> > * Community bandwidth isn't zero-sum. This particularly applies to
> people working on features that are only present in trunk, like EC, shell
> script rewrite, etc.
>
>
> A bunch of us are going to be busy with finishing 2.8.0. It isn’t
> zero-sum, but it predicates those of us involved with 2.8.0 from looking at
> it, even though we are very interested in doing so.
>
> There's a plan for more 3.0.0 alphas, so there's still time to help out
before things settle down for beta. If 2.8.0 is ready to go, it should
happen before even alpha2.
>
> Obviously, I am not making the case that this issue won’t happen ever. In
> fact, this already happened with the parallel 2.6.x and 2.7.x releases. And
> we precisely avoided major confusion there by lining up 2.7.2 behind 2.6.3
> etc.
>
Could you clarify how lining up releases differently avoids the fix version
issue?
What we've been doing is something like "one fix version per active release
line". Since we've revived 3.x as a release line, it seems like a lot of
JIRAs need 3.x fix versions now.
As an aside, I honestly don't know how to interpret the fix version
instructions on the HowToCommit wiki. They don't seem to match up with what
we actually do in practice.
Best,
Andrew
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
<vi...@apache.org> wrote:
>> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible for downstreams to test incompat changes and new features without a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version issue.
>
> Not arguing against the need for an alpha release, the question is if it can wait till after 2.8 gets done.
>
> Orthogonally, do we have a report of the incompatible changes? Like the one I generated for some of the branch-2 releases using late jdiff work from Li Lu etc. We should do this and fix any inadvertant incompatibilities. Without seeing this list of incompatibilities, why even make an alpha release and force downstream components to discover issues what can be identified through running reports.
>
I can come up with this, atleast for Source / Binary API compatibility,
provided folks don't mind if I use the Java API Compliance Checker[1]
instead of jdiff.
I'm already familiar with quickly using it, esp with Audience
Annotations from my work in HBase.
Do you want this check from some particular branch-2 release? It
matters since the releases along branch-2 have themselves had some
noise[2].
[1]: https://github.com/lvc/japi-compliance-checker
[2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
Thanks for the input Vinod, inline:
> Similarly the list of features we are enabling in this alpha would be good
> - may be update the Roadmap wiki. Things like classpath-isolation which
> were part of the original 3.x roadmap are still not done.
>
> I already updated the website release notes at HADOOP-13383. I can update
the Roadmap wiki and break out what's new in alpha1 too, thanks for the
reminder.
> > * Community bandwidth isn't zero-sum. This particularly applies to
> people working on features that are only present in trunk, like EC, shell
> script rewrite, etc.
>
>
> A bunch of us are going to be busy with finishing 2.8.0. It isn’t
> zero-sum, but it predicates those of us involved with 2.8.0 from looking at
> it, even though we are very interested in doing so.
>
> There's a plan for more 3.0.0 alphas, so there's still time to help out
before things settle down for beta. If 2.8.0 is ready to go, it should
happen before even alpha2.
>
> Obviously, I am not making the case that this issue won’t happen ever. In
> fact, this already happened with the parallel 2.6.x and 2.7.x releases. And
> we precisely avoided major confusion there by lining up 2.7.2 behind 2.6.3
> etc.
>
Could you clarify how lining up releases differently avoids the fix version
issue?
What we've been doing is something like "one fix version per active release
line". Since we've revived 3.x as a release line, it seems like a lot of
JIRAs need 3.x fix versions now.
As an aside, I honestly don't know how to interpret the fix version
instructions on the HowToCommit wiki. They don't seem to match up with what
we actually do in practice.
Best,
Andrew
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
<vi...@apache.org> wrote:
>> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible for downstreams to test incompat changes and new features without a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version issue.
>
> Not arguing against the need for an alpha release, the question is if it can wait till after 2.8 gets done.
>
> Orthogonally, do we have a report of the incompatible changes? Like the one I generated for some of the branch-2 releases using late jdiff work from Li Lu etc. We should do this and fix any inadvertant incompatibilities. Without seeing this list of incompatibilities, why even make an alpha release and force downstream components to discover issues what can be identified through running reports.
>
I can come up with this, atleast for Source / Binary API compatibility,
provided folks don't mind if I use the Java API Compliance Checker[1]
instead of jdiff.
I'm already familiar with quickly using it, esp with Audience
Annotations from my work in HBase.
Do you want this check from some particular branch-2 release? It
matters since the releases along branch-2 have themselves had some
noise[2].
[1]: https://github.com/lvc/japi-compliance-checker
[2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible for downstreams to test incompat changes and new features without a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version issue.
Not arguing against the need for an alpha release, the question is if it can wait till after 2.8 gets done.
Orthogonally, do we have a report of the incompatible changes? Like the one I generated for some of the branch-2 releases using late jdiff work from Li Lu etc. We should do this and fix any inadvertant incompatibilities. Without seeing this list of incompatibilities, why even make an alpha release and force downstream components to discover issues what can be identified through running reports.
Similarly the list of features we are enabling in this alpha would be good - may be update the Roadmap wiki. Things like classpath-isolation which were part of the original 3.x roadmap are still not done.
> * Community bandwidth isn't zero-sum. This particularly applies to people working on features that are only present in trunk, like EC, shell script rewrite, etc.
A bunch of us are going to be busy with finishing 2.8.0. It isn’t zero-sum, but it predicates those of us involved with 2.8.0 from looking at it, even though we are very interested in doing so.
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still have the issue of things committed for 2.9.0 that will be appearing for the first timein 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs, it's only incrementally more work to also fix up 2.8 and other unreleased versions too.
Obviously, I am not making the case that this issue won’t happen ever. In fact, this already happened with the parallel 2.6.x and 2.7.x releases. And we precisely avoided major confusion there by lining up 2.7.2 behind 2.6.3 etc.
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
RE: Setting JIRA fix versions for 3.0.0 releases
Posted by "Zheng, Kai" <ka...@intel.com>.
My humble feeling is almost the same regarding the urgent need of a 3.0 alpha release.
Considering EC, shell-script rewriting and etc. are significant changes and there are interested users that want to evaluate EC storage method, an alpha 3.0 release will definitely help a lot allowing users to try the new features and then expose critical bugs or gaps. This may take quite some time, and should be very important to build confidence preparing for a solid 3.0 release. I understand Vinod's concern and the need of lining up the release efforts, so if it's to work on multiple 2.x releases it should be avoided. Mentioning 3.0 alpha, it's different and the best would be to allow parallel going to speed up EC and the like, meanwhile any 2.x release won't be in a hurry pushed by 3.0 release.
Thanks for any consideration.
Regards,
Kai
-----Original Message-----
From: Andrew Wang [mailto:andrew.wang@cloudera.com]
Sent: Friday, July 22, 2016 3:33 AM
To: Vinod Kumar Vavilapalli <vi...@apache.org>
Cc: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: Re: Setting JIRA fix versions for 3.0.0 releases
I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible for downstreams to test incompat changes and new features without a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version issue.
I'm not too worried about splitting community bandwidth, for the following
reasons:
* 3.0.0-alpha1 is very explicitly an alpha, which means no quality or compatibility guarantees. It needs less vetting than a 2.x release.
* Given that 3.0.0 is still in alpha, there aren't many true showstopper bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0.
* Community bandwidth isn't zero-sum. This particularly applies to people working on features that are only present in trunk, like EC, shell script rewrite, etc.
Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still have the issue of things committed for 2.9.0 that will be appearing for the first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs, it's only incrementally more work to also fix up 2.8 and other unreleased versions too.
Best,
Andrew
On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli < vinodkv@apache.org> wrote:
> The L & N fixes just went out, I’m working to push out 2.7.3 - running
> into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
>
> Like I requested before in one of the 3.x threads, can we just line up
> 3.0.0-alpha1 right behind 2.8.0?
>
> That simplifies most of this confusion, we can avoid splitting the
> bandwidth from the community on fixing blockers / vetting these
> concurrent releases. Waiting a little more for 3.0.0 alpha to avoid
> most of this is worth it, IMO.
>
> Thanks
> +Vinod
>
> > On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> > Hi all,
> >
> > Since we're planning to spin releases off of both branch-2 and
> > trunk, the changelog for 3.0.0-alpha1 based on JIRA information
> > isn't accurate. This is because historically, we've only set 2.x fix
> > versions, and 2.8.0 and
> > 2.9.0 and etc have not been released. So there's a whole bunch of
> > changes which will show up for the first time in 3.0.0-alpha1.
> >
> > I think I can write a script to (carefully) add 3.0.0-alpha1 to
> > these JIRAs, but I figured I'd give a heads up here in case anyone
> > felt differently. I can also update the HowToCommit page to match.
> >
> > Thanks,
> > Andrew
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible for downstreams to test incompat changes and new features without a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version issue.
Not arguing against the need for an alpha release, the question is if it can wait till after 2.8 gets done.
Orthogonally, do we have a report of the incompatible changes? Like the one I generated for some of the branch-2 releases using late jdiff work from Li Lu etc. We should do this and fix any inadvertant incompatibilities. Without seeing this list of incompatibilities, why even make an alpha release and force downstream components to discover issues what can be identified through running reports.
Similarly the list of features we are enabling in this alpha would be good - may be update the Roadmap wiki. Things like classpath-isolation which were part of the original 3.x roadmap are still not done.
> * Community bandwidth isn't zero-sum. This particularly applies to people working on features that are only present in trunk, like EC, shell script rewrite, etc.
A bunch of us are going to be busy with finishing 2.8.0. It isn’t zero-sum, but it predicates those of us involved with 2.8.0 from looking at it, even though we are very interested in doing so.
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still have the issue of things committed for 2.9.0 that will be appearing for the first timein 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs, it's only incrementally more work to also fix up 2.8 and other unreleased versions too.
Obviously, I am not making the case that this issue won’t happen ever. In fact, this already happened with the parallel 2.6.x and 2.7.x releases. And we precisely avoided major confusion there by lining up 2.7.2 behind 2.6.3 etc.
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
> have the issue of things committed for 2.9.0 that will be appearing for the
> first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
> it's only incrementally more work to also fix up 2.8 and other unreleased
> versions too.
This. this is why I've been a bit confused on folks not wanting to
invest the time in getting multiple major branches working correctly.
With my "Hadoop community" hat on, I see that we struggle with
maintaining multiple maintenance lines just within 2.y and I worry how
we're going to do once 3.y is going.
With my downstream "HBase community" hat on, I'm pretty sure I still
need there to still be 2.y releases. AFAIK the HBase community hasn't
made any plans to e.g. abandon Hadoop 2.y versions in our next major
release and we'd be very sad if all future features we needed added to
e.g. HDFS forced our users to upgrade across a major version.
On Thu, Jul 21, 2016 at 2:33 PM, Andrew Wang <an...@cloudera.com> wrote:
> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible
> for downstreams to test incompat changes and new features without a release
> artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for
> an RC besides possibly this fix version issue.
>
> I'm not too worried about splitting community bandwidth, for the following
> reasons:
>
> * 3.0.0-alpha1 is very explicitly an alpha, which means no quality or
> compatibility guarantees. It needs less vetting than a 2.x release.
> * Given that 3.0.0 is still in alpha, there aren't many true showstopper
> bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0.
> * Community bandwidth isn't zero-sum. This particularly applies to people
> working on features that are only present in trunk, like EC, shell script
> rewrite, etc.
>
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
> have the issue of things committed for 2.9.0 that will be appearing for the
> first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
> it's only incrementally more work to also fix up 2.8 and other unreleased
> versions too.
>
> Best,
> Andrew
>
> On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org> wrote:
>
>> The L & N fixes just went out, I’m working to push out 2.7.3 - running
>> into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
>>
>> Like I requested before in one of the 3.x threads, can we just line up
>> 3.0.0-alpha1 right behind 2.8.0?
>>
>> That simplifies most of this confusion, we can avoid splitting the
>> bandwidth from the community on fixing blockers / vetting these concurrent
>> releases. Waiting a little more for 3.0.0 alpha to avoid most of this is
>> worth it, IMO.
>>
>> Thanks
>> +Vinod
>>
>> > On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> >
>> > Hi all,
>> >
>> > Since we're planning to spin releases off of both branch-2 and trunk, the
>> > changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This
>> > is because historically, we've only set 2.x fix versions, and 2.8.0 and
>> > 2.9.0 and etc have not been released. So there's a whole bunch of changes
>> > which will show up for the first time in 3.0.0-alpha1.
>> >
>> > I think I can write a script to (carefully) add 3.0.0-alpha1 to these
>> > JIRAs, but I figured I'd give a heads up here in case anyone felt
>> > differently. I can also update the HowToCommit page to match.
>> >
>> > Thanks,
>> > Andrew
>>
>>
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
RE: Setting JIRA fix versions for 3.0.0 releases
Posted by "Zheng, Kai" <ka...@intel.com>.
My humble feeling is almost the same regarding the urgent need of a 3.0 alpha release.
Considering EC, shell-script rewriting and etc. are significant changes and there are interested users that want to evaluate EC storage method, an alpha 3.0 release will definitely help a lot allowing users to try the new features and then expose critical bugs or gaps. This may take quite some time, and should be very important to build confidence preparing for a solid 3.0 release. I understand Vinod's concern and the need of lining up the release efforts, so if it's to work on multiple 2.x releases it should be avoided. Mentioning 3.0 alpha, it's different and the best would be to allow parallel going to speed up EC and the like, meanwhile any 2.x release won't be in a hurry pushed by 3.0 release.
Thanks for any consideration.
Regards,
Kai
-----Original Message-----
From: Andrew Wang [mailto:andrew.wang@cloudera.com]
Sent: Friday, July 22, 2016 3:33 AM
To: Vinod Kumar Vavilapalli <vi...@apache.org>
Cc: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: Re: Setting JIRA fix versions for 3.0.0 releases
I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible for downstreams to test incompat changes and new features without a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version issue.
I'm not too worried about splitting community bandwidth, for the following
reasons:
* 3.0.0-alpha1 is very explicitly an alpha, which means no quality or compatibility guarantees. It needs less vetting than a 2.x release.
* Given that 3.0.0 is still in alpha, there aren't many true showstopper bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0.
* Community bandwidth isn't zero-sum. This particularly applies to people working on features that are only present in trunk, like EC, shell script rewrite, etc.
Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still have the issue of things committed for 2.9.0 that will be appearing for the first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs, it's only incrementally more work to also fix up 2.8 and other unreleased versions too.
Best,
Andrew
On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli < vinodkv@apache.org> wrote:
> The L & N fixes just went out, I’m working to push out 2.7.3 - running
> into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
>
> Like I requested before in one of the 3.x threads, can we just line up
> 3.0.0-alpha1 right behind 2.8.0?
>
> That simplifies most of this confusion, we can avoid splitting the
> bandwidth from the community on fixing blockers / vetting these
> concurrent releases. Waiting a little more for 3.0.0 alpha to avoid
> most of this is worth it, IMO.
>
> Thanks
> +Vinod
>
> > On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> > Hi all,
> >
> > Since we're planning to spin releases off of both branch-2 and
> > trunk, the changelog for 3.0.0-alpha1 based on JIRA information
> > isn't accurate. This is because historically, we've only set 2.x fix
> > versions, and 2.8.0 and
> > 2.9.0 and etc have not been released. So there's a whole bunch of
> > changes which will show up for the first time in 3.0.0-alpha1.
> >
> > I think I can write a script to (carefully) add 3.0.0-alpha1 to
> > these JIRAs, but I figured I'd give a heads up here in case anyone
> > felt differently. I can also update the HowToCommit page to match.
> >
> > Thanks,
> > Andrew
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
> have the issue of things committed for 2.9.0 that will be appearing for the
> first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
> it's only incrementally more work to also fix up 2.8 and other unreleased
> versions too.
This. this is why I've been a bit confused on folks not wanting to
invest the time in getting multiple major branches working correctly.
With my "Hadoop community" hat on, I see that we struggle with
maintaining multiple maintenance lines just within 2.y and I worry how
we're going to do once 3.y is going.
With my downstream "HBase community" hat on, I'm pretty sure I still
need there to still be 2.y releases. AFAIK the HBase community hasn't
made any plans to e.g. abandon Hadoop 2.y versions in our next major
release and we'd be very sad if all future features we needed added to
e.g. HDFS forced our users to upgrade across a major version.
On Thu, Jul 21, 2016 at 2:33 PM, Andrew Wang <an...@cloudera.com> wrote:
> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible
> for downstreams to test incompat changes and new features without a release
> artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for
> an RC besides possibly this fix version issue.
>
> I'm not too worried about splitting community bandwidth, for the following
> reasons:
>
> * 3.0.0-alpha1 is very explicitly an alpha, which means no quality or
> compatibility guarantees. It needs less vetting than a 2.x release.
> * Given that 3.0.0 is still in alpha, there aren't many true showstopper
> bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0.
> * Community bandwidth isn't zero-sum. This particularly applies to people
> working on features that are only present in trunk, like EC, shell script
> rewrite, etc.
>
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
> have the issue of things committed for 2.9.0 that will be appearing for the
> first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
> it's only incrementally more work to also fix up 2.8 and other unreleased
> versions too.
>
> Best,
> Andrew
>
> On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org> wrote:
>
>> The L & N fixes just went out, I’m working to push out 2.7.3 - running
>> into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
>>
>> Like I requested before in one of the 3.x threads, can we just line up
>> 3.0.0-alpha1 right behind 2.8.0?
>>
>> That simplifies most of this confusion, we can avoid splitting the
>> bandwidth from the community on fixing blockers / vetting these concurrent
>> releases. Waiting a little more for 3.0.0 alpha to avoid most of this is
>> worth it, IMO.
>>
>> Thanks
>> +Vinod
>>
>> > On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> >
>> > Hi all,
>> >
>> > Since we're planning to spin releases off of both branch-2 and trunk, the
>> > changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This
>> > is because historically, we've only set 2.x fix versions, and 2.8.0 and
>> > 2.9.0 and etc have not been released. So there's a whole bunch of changes
>> > which will show up for the first time in 3.0.0-alpha1.
>> >
>> > I think I can write a script to (carefully) add 3.0.0-alpha1 to these
>> > JIRAs, but I figured I'd give a heads up here in case anyone felt
>> > differently. I can also update the HowToCommit page to match.
>> >
>> > Thanks,
>> > Andrew
>>
>>
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Sean Busbey <bu...@cloudera.com>.
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
> have the issue of things committed for 2.9.0 that will be appearing for the
> first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
> it's only incrementally more work to also fix up 2.8 and other unreleased
> versions too.
This. this is why I've been a bit confused on folks not wanting to
invest the time in getting multiple major branches working correctly.
With my "Hadoop community" hat on, I see that we struggle with
maintaining multiple maintenance lines just within 2.y and I worry how
we're going to do once 3.y is going.
With my downstream "HBase community" hat on, I'm pretty sure I still
need there to still be 2.y releases. AFAIK the HBase community hasn't
made any plans to e.g. abandon Hadoop 2.y versions in our next major
release and we'd be very sad if all future features we needed added to
e.g. HDFS forced our users to upgrade across a major version.
On Thu, Jul 21, 2016 at 2:33 PM, Andrew Wang <an...@cloudera.com> wrote:
> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible
> for downstreams to test incompat changes and new features without a release
> artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for
> an RC besides possibly this fix version issue.
>
> I'm not too worried about splitting community bandwidth, for the following
> reasons:
>
> * 3.0.0-alpha1 is very explicitly an alpha, which means no quality or
> compatibility guarantees. It needs less vetting than a 2.x release.
> * Given that 3.0.0 is still in alpha, there aren't many true showstopper
> bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0.
> * Community bandwidth isn't zero-sum. This particularly applies to people
> working on features that are only present in trunk, like EC, shell script
> rewrite, etc.
>
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
> have the issue of things committed for 2.9.0 that will be appearing for the
> first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
> it's only incrementally more work to also fix up 2.8 and other unreleased
> versions too.
>
> Best,
> Andrew
>
> On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org> wrote:
>
>> The L & N fixes just went out, I’m working to push out 2.7.3 - running
>> into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
>>
>> Like I requested before in one of the 3.x threads, can we just line up
>> 3.0.0-alpha1 right behind 2.8.0?
>>
>> That simplifies most of this confusion, we can avoid splitting the
>> bandwidth from the community on fixing blockers / vetting these concurrent
>> releases. Waiting a little more for 3.0.0 alpha to avoid most of this is
>> worth it, IMO.
>>
>> Thanks
>> +Vinod
>>
>> > On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> >
>> > Hi all,
>> >
>> > Since we're planning to spin releases off of both branch-2 and trunk, the
>> > changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This
>> > is because historically, we've only set 2.x fix versions, and 2.8.0 and
>> > 2.9.0 and etc have not been released. So there's a whole bunch of changes
>> > which will show up for the first time in 3.0.0-alpha1.
>> >
>> > I think I can write a script to (carefully) add 3.0.0-alpha1 to these
>> > JIRAs, but I figured I'd give a heads up here in case anyone felt
>> > differently. I can also update the HowToCommit page to match.
>> >
>> > Thanks,
>> > Andrew
>>
>>
--
busbey
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
RE: Setting JIRA fix versions for 3.0.0 releases
Posted by "Zheng, Kai" <ka...@intel.com>.
My humble feeling is almost the same regarding the urgent need of a 3.0 alpha release.
Considering EC, shell-script rewriting and etc. are significant changes and there are interested users that want to evaluate EC storage method, an alpha 3.0 release will definitely help a lot allowing users to try the new features and then expose critical bugs or gaps. This may take quite some time, and should be very important to build confidence preparing for a solid 3.0 release. I understand Vinod's concern and the need of lining up the release efforts, so if it's to work on multiple 2.x releases it should be avoided. Mentioning 3.0 alpha, it's different and the best would be to allow parallel going to speed up EC and the like, meanwhile any 2.x release won't be in a hurry pushed by 3.0 release.
Thanks for any consideration.
Regards,
Kai
-----Original Message-----
From: Andrew Wang [mailto:andrew.wang@cloudera.com]
Sent: Friday, July 22, 2016 3:33 AM
To: Vinod Kumar Vavilapalli <vi...@apache.org>
Cc: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: Re: Setting JIRA fix versions for 3.0.0 releases
I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible for downstreams to test incompat changes and new features without a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version issue.
I'm not too worried about splitting community bandwidth, for the following
reasons:
* 3.0.0-alpha1 is very explicitly an alpha, which means no quality or compatibility guarantees. It needs less vetting than a 2.x release.
* Given that 3.0.0 is still in alpha, there aren't many true showstopper bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0.
* Community bandwidth isn't zero-sum. This particularly applies to people working on features that are only present in trunk, like EC, shell script rewrite, etc.
Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still have the issue of things committed for 2.9.0 that will be appearing for the first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs, it's only incrementally more work to also fix up 2.8 and other unreleased versions too.
Best,
Andrew
On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli < vinodkv@apache.org> wrote:
> The L & N fixes just went out, I’m working to push out 2.7.3 - running
> into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
>
> Like I requested before in one of the 3.x threads, can we just line up
> 3.0.0-alpha1 right behind 2.8.0?
>
> That simplifies most of this confusion, we can avoid splitting the
> bandwidth from the community on fixing blockers / vetting these
> concurrent releases. Waiting a little more for 3.0.0 alpha to avoid
> most of this is worth it, IMO.
>
> Thanks
> +Vinod
>
> > On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> > Hi all,
> >
> > Since we're planning to spin releases off of both branch-2 and
> > trunk, the changelog for 3.0.0-alpha1 based on JIRA information
> > isn't accurate. This is because historically, we've only set 2.x fix
> > versions, and 2.8.0 and
> > 2.9.0 and etc have not been released. So there's a whole bunch of
> > changes which will show up for the first time in 3.0.0-alpha1.
> >
> > I think I can write a script to (carefully) add 3.0.0-alpha1 to
> > these JIRAs, but I figured I'd give a heads up here in case anyone
> > felt differently. I can also update the HowToCommit page to match.
> >
> > Thanks,
> > Andrew
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible for downstreams to test incompat changes and new features without a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version issue.
Not arguing against the need for an alpha release, the question is if it can wait till after 2.8 gets done.
Orthogonally, do we have a report of the incompatible changes? Like the one I generated for some of the branch-2 releases using late jdiff work from Li Lu etc. We should do this and fix any inadvertant incompatibilities. Without seeing this list of incompatibilities, why even make an alpha release and force downstream components to discover issues what can be identified through running reports.
Similarly the list of features we are enabling in this alpha would be good - may be update the Roadmap wiki. Things like classpath-isolation which were part of the original 3.x roadmap are still not done.
> * Community bandwidth isn't zero-sum. This particularly applies to people working on features that are only present in trunk, like EC, shell script rewrite, etc.
A bunch of us are going to be busy with finishing 2.8.0. It isn’t zero-sum, but it predicates those of us involved with 2.8.0 from looking at it, even though we are very interested in doing so.
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still have the issue of things committed for 2.9.0 that will be appearing for the first timein 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs, it's only incrementally more work to also fix up 2.8 and other unreleased versions too.
Obviously, I am not making the case that this issue won’t happen ever. In fact, this already happened with the parallel 2.6.x and 2.7.x releases. And we precisely avoided major confusion there by lining up 2.7.2 behind 2.6.3 etc.
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible
for downstreams to test incompat changes and new features without a release
artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for
an RC besides possibly this fix version issue.
I'm not too worried about splitting community bandwidth, for the following
reasons:
* 3.0.0-alpha1 is very explicitly an alpha, which means no quality or
compatibility guarantees. It needs less vetting than a 2.x release.
* Given that 3.0.0 is still in alpha, there aren't many true showstopper
bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0.
* Community bandwidth isn't zero-sum. This particularly applies to people
working on features that are only present in trunk, like EC, shell script
rewrite, etc.
Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
have the issue of things committed for 2.9.0 that will be appearing for the
first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
it's only incrementally more work to also fix up 2.8 and other unreleased
versions too.
Best,
Andrew
On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli <
vinodkv@apache.org> wrote:
> The L & N fixes just went out, I’m working to push out 2.7.3 - running
> into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
>
> Like I requested before in one of the 3.x threads, can we just line up
> 3.0.0-alpha1 right behind 2.8.0?
>
> That simplifies most of this confusion, we can avoid splitting the
> bandwidth from the community on fixing blockers / vetting these concurrent
> releases. Waiting a little more for 3.0.0 alpha to avoid most of this is
> worth it, IMO.
>
> Thanks
> +Vinod
>
> > On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> > Hi all,
> >
> > Since we're planning to spin releases off of both branch-2 and trunk, the
> > changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This
> > is because historically, we've only set 2.x fix versions, and 2.8.0 and
> > 2.9.0 and etc have not been released. So there's a whole bunch of changes
> > which will show up for the first time in 3.0.0-alpha1.
> >
> > I think I can write a script to (carefully) add 3.0.0-alpha1 to these
> > JIRAs, but I figured I'd give a heads up here in case anyone felt
> > differently. I can also update the HowToCommit page to match.
> >
> > Thanks,
> > Andrew
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible
for downstreams to test incompat changes and new features without a release
artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for
an RC besides possibly this fix version issue.
I'm not too worried about splitting community bandwidth, for the following
reasons:
* 3.0.0-alpha1 is very explicitly an alpha, which means no quality or
compatibility guarantees. It needs less vetting than a 2.x release.
* Given that 3.0.0 is still in alpha, there aren't many true showstopper
bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0.
* Community bandwidth isn't zero-sum. This particularly applies to people
working on features that are only present in trunk, like EC, shell script
rewrite, etc.
Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
have the issue of things committed for 2.9.0 that will be appearing for the
first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
it's only incrementally more work to also fix up 2.8 and other unreleased
versions too.
Best,
Andrew
On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli <
vinodkv@apache.org> wrote:
> The L & N fixes just went out, I’m working to push out 2.7.3 - running
> into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
>
> Like I requested before in one of the 3.x threads, can we just line up
> 3.0.0-alpha1 right behind 2.8.0?
>
> That simplifies most of this confusion, we can avoid splitting the
> bandwidth from the community on fixing blockers / vetting these concurrent
> releases. Waiting a little more for 3.0.0 alpha to avoid most of this is
> worth it, IMO.
>
> Thanks
> +Vinod
>
> > On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> > Hi all,
> >
> > Since we're planning to spin releases off of both branch-2 and trunk, the
> > changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This
> > is because historically, we've only set 2.x fix versions, and 2.8.0 and
> > 2.9.0 and etc have not been released. So there's a whole bunch of changes
> > which will show up for the first time in 3.0.0-alpha1.
> >
> > I think I can write a script to (carefully) add 3.0.0-alpha1 to these
> > JIRAs, but I figured I'd give a heads up here in case anyone felt
> > differently. I can also update the HowToCommit page to match.
> >
> > Thanks,
> > Andrew
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Andrew Wang <an...@cloudera.com>.
I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible
for downstreams to test incompat changes and new features without a release
artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for
an RC besides possibly this fix version issue.
I'm not too worried about splitting community bandwidth, for the following
reasons:
* 3.0.0-alpha1 is very explicitly an alpha, which means no quality or
compatibility guarantees. It needs less vetting than a 2.x release.
* Given that 3.0.0 is still in alpha, there aren't many true showstopper
bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0.
* Community bandwidth isn't zero-sum. This particularly applies to people
working on features that are only present in trunk, like EC, shell script
rewrite, etc.
Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
have the issue of things committed for 2.9.0 that will be appearing for the
first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
it's only incrementally more work to also fix up 2.8 and other unreleased
versions too.
Best,
Andrew
On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli <
vinodkv@apache.org> wrote:
> The L & N fixes just went out, I’m working to push out 2.7.3 - running
> into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
>
> Like I requested before in one of the 3.x threads, can we just line up
> 3.0.0-alpha1 right behind 2.8.0?
>
> That simplifies most of this confusion, we can avoid splitting the
> bandwidth from the community on fixing blockers / vetting these concurrent
> releases. Waiting a little more for 3.0.0 alpha to avoid most of this is
> worth it, IMO.
>
> Thanks
> +Vinod
>
> > On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> > Hi all,
> >
> > Since we're planning to spin releases off of both branch-2 and trunk, the
> > changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This
> > is because historically, we've only set 2.x fix versions, and 2.8.0 and
> > 2.9.0 and etc have not been released. So there's a whole bunch of changes
> > which will show up for the first time in 3.0.0-alpha1.
> >
> > I think I can write a script to (carefully) add 3.0.0-alpha1 to these
> > JIRAs, but I figured I'd give a heads up here in case anyone felt
> > differently. I can also update the HowToCommit page to match.
> >
> > Thanks,
> > Andrew
>
>
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
The L & N fixes just went out, I’m working to push out 2.7.3 - running into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
Like I requested before in one of the 3.x threads, can we just line up 3.0.0-alpha1 right behind 2.8.0?
That simplifies most of this confusion, we can avoid splitting the bandwidth from the community on fixing blockers / vetting these concurrent releases. Waiting a little more for 3.0.0 alpha to avoid most of this is worth it, IMO.
Thanks
+Vinod
> On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com> wrote:
>
> Hi all,
>
> Since we're planning to spin releases off of both branch-2 and trunk, the
> changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This
> is because historically, we've only set 2.x fix versions, and 2.8.0 and
> 2.9.0 and etc have not been released. So there's a whole bunch of changes
> which will show up for the first time in 3.0.0-alpha1.
>
> I think I can write a script to (carefully) add 3.0.0-alpha1 to these
> JIRAs, but I figured I'd give a heads up here in case anyone felt
> differently. I can also update the HowToCommit page to match.
>
> Thanks,
> Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
The L & N fixes just went out, I’m working to push out 2.7.3 - running into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
Like I requested before in one of the 3.x threads, can we just line up 3.0.0-alpha1 right behind 2.8.0?
That simplifies most of this confusion, we can avoid splitting the bandwidth from the community on fixing blockers / vetting these concurrent releases. Waiting a little more for 3.0.0 alpha to avoid most of this is worth it, IMO.
Thanks
+Vinod
> On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com> wrote:
>
> Hi all,
>
> Since we're planning to spin releases off of both branch-2 and trunk, the
> changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This
> is because historically, we've only set 2.x fix versions, and 2.8.0 and
> 2.9.0 and etc have not been released. So there's a whole bunch of changes
> which will show up for the first time in 3.0.0-alpha1.
>
> I think I can write a script to (carefully) add 3.0.0-alpha1 to these
> JIRAs, but I figured I'd give a heads up here in case anyone felt
> differently. I can also update the HowToCommit page to match.
>
> Thanks,
> Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Setting JIRA fix versions for 3.0.0 releases
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
The L & N fixes just went out, I’m working to push out 2.7.3 - running into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0.
Like I requested before in one of the 3.x threads, can we just line up 3.0.0-alpha1 right behind 2.8.0?
That simplifies most of this confusion, we can avoid splitting the bandwidth from the community on fixing blockers / vetting these concurrent releases. Waiting a little more for 3.0.0 alpha to avoid most of this is worth it, IMO.
Thanks
+Vinod
> On Jul 21, 2016, at 11:34 AM, Andrew Wang <an...@cloudera.com> wrote:
>
> Hi all,
>
> Since we're planning to spin releases off of both branch-2 and trunk, the
> changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This
> is because historically, we've only set 2.x fix versions, and 2.8.0 and
> 2.9.0 and etc have not been released. So there's a whole bunch of changes
> which will show up for the first time in 3.0.0-alpha1.
>
> I think I can write a script to (carefully) add 3.0.0-alpha1 to these
> JIRAs, but I figured I'd give a heads up here in case anyone felt
> differently. I can also update the HowToCommit page to match.
>
> Thanks,
> Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org