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 <vino...@apache.org <javascript:_e(%7B%7D,'cvml','vino...@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-unsubscr...@hadoop.apache.org > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > >
