>> 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
