hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: Setting JIRA fix versions for 3.0.0 releases
Date Mon, 25 Jul 2016 18:02:34 GMT
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.


On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <aw@effectivemachines.com>

> > On Jul 22, 2016, at 7:16 PM, Andrew Wang <andrew.wang@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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message