> On Jul 22, 2016, at 7:16 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > > Does this mean you find our current system of listing a JIRA as being fixed > in both a 2.6.x and 2.7.x to be confusing?
Nope. I'm only confused when there isn't a .0 release in the fix line. When I see 2.6.x and 2.7.x I know that it was back ported to those branches. If I don't see a .0, I figure it's either a mistake or something that was already fixed by another change in that major/minor branch. It's almost always the former, however. > FWIW, my usecase is normally not "what is the earliest release that has this > fix?" but rather "is this fix in this release?". If it's easy to query the > latter, you can also determine the former. Some kind of query tool could help > here. It literally becomes a grep if people commit the release data into the source tree, the release data is correct, etc: $ mvn install site -Preleasedocs -Pdocs -DskipTests $ grep issueid hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES* We should probably update the release process to make sure that *in progress* release data is also committed when a .0 is cut. That's likely missing. Another choice would be to modify the pom to that runs releasedocmaker to use a range rather than single version, but that gets a bit tricky with release dates, how big of a range, etc. Not impossible, just tricky. Probably needs to be script that gets run as part of create-release, maybe? (In reality, I do this grep against my git repo that generates the change log data automatically. This way it is always up-to-date and not dependent upon release data being committed. But that same grep could be done with a JQL query just as easily.) > For the release notes, am I correct in interpreting this as: > > * diff a.0.0 from the previous x.y.0 release > * diff a.b.0 from the previous a.0.0 or a.b.0 release > * diff a.b.c from the previous a.b.0 or a.b.c release Pretty much yes. > Ray pointed me at the changelogs of a few other enterprise software products, > and this strategy seems pretty common. I like it. It's extremely common, to the point that putting every fix for every release touched is, at least to me, weird and extremely unconventional. > I realize now that this means a lot more JIRAs will need the 2.8.0 fix > version, since they only have 2.6.x and 2.7.x. Yup. > This makes the fix rules actually pretty easy: the lowest a.b.0 release > and all non-.0 releases. > > I think this needs to be amended to handle the case of multiple major release > branches, since we could have something committed for both 2.9.0 and 3.1.0. > So "lowest a.b.0 release within each major version"? Yeah, switching to effectively trunk-based development makes the rules harder. It's one of the reasons why the two big enterprisey companies I worked at prior to working on Hadoop didn't really do trunk-based for the vast majority of projects. They always cut a branch (or equivalent for that SCM) to delineate a break. Given the amount of ex-Sun folks involved in the early days of Hadoop, our pre-existing development processes very much reflect that culture. > This was true previously (no releases from trunk, trunk is versioned a.0.0), > but now that trunk is essentially a minor release branch, its fix version > needs to be treated as such. Yeah, I misspoke a bit when dealing with a head-of-tree model. 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously. Every 3.0.0-(label) release is effectively a major version in that case. --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org