If I don't hear otherwise, I'd like to go ahead and do the bulk fix version update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD tomorrow in case there's more discussion. If any one is willing to help review my script and JIRA queries, that'd also be great.
I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should be a very similar process. Best, Andrew On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <a...@effectivemachines.com> wrote: > > > 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. > > >
