hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wangda Tan <wheele...@gmail.com>
Subject Re: Setting JIRA fix versions for 3.0.0 releases
Date Tue, 26 Jul 2016 00:57:16 GMT
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.wang@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 <
> aw@effectivemachines.com>
> wrote:
>
> >
> > > 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.
> >
> >
> >
>

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