> > >> 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.
