> On Jul 22, 2016, at 7:16 PM, Andrew Wang <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
