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