Hi Andrew, Please wait updating fix version for branch-2 committed tickets before we get a consensus on this. Updating fix versions for them could bring lots of troubles for on going two releases (2.7.3 / 2.8.0).
Thanks, Wangda On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang <andrew.w...@cloudera.com> wrote: > 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. > > > > > > >
