Thanks Vinod+Wangda for the comments, Above, Allen and I discussed a proposal which I think is reasonable and also lines up well with our current approach. If you feel something is underspecified or needs improvement, please raise those points.
We have been doing concurrent releases with the 2.6.x and 2.7.x lines, so it's not entirely new ground. I believe we also haven't been doing purely-chronological changelogs, since a JIRA can have fix versions of both 2.6.x and 2.7.x. The above proposal can be viewed as an extension of what we're already doing for concurrent minor release branches to major release branches. The JIRA bulk update I want do to is add 3.0.0-alpha1 versions. Since we're only adding, it won't affect the 2.8.0 or other release notes. I offered to do a 2.8.0 JIRA bulk update since I already have the script, but I can also just publish it and let someone else handle 2.8.0. We do need to agree on the ordering of 2.8.0 and 3.0.0-alpha1 so 3's "base" version makes sense chronologically. I'd like to base 3 off of 2.7.0, since 2.8.0 still has a number of unresolved blockers. Finally, with some hackery, we've recently been able to compile the projects in CDH against a Hadoop 3 snapshot. As part of the HDFS EC effort, many contributors have already been testing Hadoop 3 snapshots on multi-node clusters. So, I have confidence that what we have now is already a useful artifact for downstreams, since downstreams are already trying to consume it. Best, Andrew On Mon, Jul 25, 2016 at 5:57 PM, Wangda Tan <wheele...@gmail.com> wrote: > 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. >> > >> > >> > >> > >
