hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: Setting JIRA fix versions for 3.0.0 releases
Date Fri, 22 Jul 2016 18:44:43 GMT
>
>
>> I am also not quite sure I understand the rationale of what's in the
> HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as
> our baseline thinking, having concurrent release streams alone breaks the
> principle. And that is *regardless of* how we line up individual releases
> in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where *
> is any number. Therefore, the moment we have any new 2.6.z release after
> 2.7.0, the rule is broken and remains that way. Timing of subsequent
> releases is somewhat irrelevant.
>
> From a practical standpoint, I would love to know whether a certain patch
> has been backported to a specific version. Thus, I would love to see fix
> version enumerating all the releases that the JIRA went into. Basically the
> more disclosure, the better. That would also make it easier for us
> committers to see the state of the porting and identify issues like being
> ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our
> policy?
>
>
I also err towards more fix versions. Based on our branching strategy of
branch-x -> branch-x.y -> branch->x.y.z, I think this means that the
changelog will identify everything since the previous
last-version-component of the branch name. So 2.6.5 diffs against 2.6.4,
2.8.0 diffs against 2.7.0, 3.0.0 against 2.0.0. This makes it more
straightforward for users to determine what changelogs are important, based
purely on the version number.

I agree with Sangjin that the #1 question that the changelogs should
address is whether a certain patch is present in a version. For this
usecase, it's better to have duplicate info than to omit something.

To answer "what's new", I think that's answered by the manually curated
release notes, like the ones we put together at HADOOP-13383.

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