Thanks for the input Allen, good perspective as always, inline:
> From the perspective of an end user who is reading multiple > versions' listings at once, listing the same JIRA being fixed in multiple > releases is totally confusing, especially now that release notes are > actually readable. "So which version was it ACTUALLY fixed in?" is going > to be the question. It'd be worthwhile for folks to actually build, say, > trunk and look at the release notes section of the site build to see how > these things are presented in aggregate before coming to any conclusions. > Just viewing a single version's output will likely give a skewed > perspective. (Or, I suppose you can read > https://gitlab.com/_a__w_/eco-release-metadata/tree/master/HADOOP too, > but the sort order is "wrong" for web viewing.) > > 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? 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. > My read of the HowToCommit fix rules is that they were written > from the perspective of how we typically use branches to cut releases. In > other words, the changes and release notes for 2.6.x, where x>0, 2.7.y, > where y>0, will likely not be fully present/complete in 2.8.0 so wouldn't > actually reflect the entirety of, say, the 2.7.4 release if 2.7.4 and 2.8.0 > are being worked in parallel. This in turn means the changes and release > notes become orthogonal once the minor release branch is cut. This is also > important because there is no guarantee that a change made in, say, 2.7.4 > is actually in 2.8.0 because the code may have changed to the point that > the fix isn't needed or wanted. > > From an automation perspective, I took the perspective that this > means that the a.b.0 release notes are expected to be committed to all > non-released major branches. So trunk will have release notes for 2.7.0, > 2.8.0, 2.9.0, etc but not from 2.7.1, 2.8.1, or 2.9.1. 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 Ray pointed me at the changelogs of a few other enterprise software products, and this strategy seems pretty common. I like it. 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. > 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"? trunk, as always, is only listed if that is the only place where it was > committed. (i.e., the lowest a.b.0 release happens to be the highest one > available.) > 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. > I suspect people are feeling confused or think the rules need to > be changed... > The explanation here is far clearer than what's on HowToCommit, particularly since the HowToCommit example branches are irrelevant in today's era. If we like this versioning strategy, I'm happy to crib some of this text and update the HowToCommit wiki. In good news, my little python script to do bulk fixVersion updates seems to work, so we can proceed posthaste once we have a plan. Thanks, Andrew
