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 [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Date Tue, 26 Jul 2016 19:07:09 GMT
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


Mime
View raw message