Please don’t do this for 2.8.0 against 2.7.0 till we change our existing release ordering conventions.
Till now, I made sure 2.8.0 only has issues that are not in 2.7.3 - per the 2.8.0-follows-2.7.3 convention. As part of the release process, I will fix the remaining tickets to follow this same convention. Again till we create new rules. Thanks +Vinod > On 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. >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
