hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kumar Vavilapalli <vino...@apache.org>
Subject Re: Setting JIRA fix versions for 3.0.0 releases
Date Mon, 25 Jul 2016 21:10:37 GMT
>> 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


Mime
View raw message