hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsuyoshi Ozawa <oz...@apache.org>
Subject [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Date Wed, 27 Jul 2016 04:51:48 GMT
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.

- Tsuyoshi

On Wednesday, 27 July 2016, Vinod Kumar Vavilapalli <vinodkv@apache.org
<javascript:_e(%7B%7D,'cvml','vinodkv@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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message