hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers" <...@cloudera.com>
Subject Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Date Thu, 29 Mar 2012 22:06:40 GMT
Thanks a lot, Scott, for bringing the discussion back to what to call
"trunk" in JIRA and elsewhere. The proposal you describe to me makes a lot
of sense.

Owen, does this (and the JIRA proposal) make sense to you?

Aaron T. Myers
Software Engineer, Cloudera

On Thu, Mar 29, 2012 at 12:45 PM, Scott Carey <scott@richrelevance.com>wrote:

> On 3/28/12 2:14 PM, "Aaron T. Myers" <atm@cloudera.com> wrote:
> >On Wed, Mar 28, 2012 at 1:57 PM, Arun C Murthy <acm@hortonworks.com>
> >wrote:
> >
> >> On on hand, we've historically bumped the version number for trunk (i.e.
> >> 3.0.0-SNAPSHOT). This has the nice property that when we do cut a
> >>release
> >> branch off trunk we don't have to scramble to change fix-versions on all
> >> the jiras committed to trunk from 'trunk' to X.0.0. Since I've done my
> >>fair
> >> share of jira manipulation for releases as the RM, as recently as last
> >> night, it's nice to not force the burden on the RM for branch-3.
> >>
> >
> >I don't think you'd have to change all the JIRAs. You'd just have to
> >change
> >the name of the "trunk" JIRA version to whatever the right number is, and
> >then create a new version in JIRA also named "trunk." This would serve the
> >same purpose, without having to update any individual JIRAs.
> >
> >
> >> OTOH, having a constant trunk-SNAPSHOT version string helps devs working
> >> on trunk since they don't have to deal with version bumps on trunk
> >>(albeit,
> >> once in a while). (Credit to Scott Carey for this idea.)
> >>
> >
> >This is a nice benefit of Todd's (and Scott's?) proposal. Whenever we do
> >change the trunk version number, I have to update a bunch of scripts,
> >environment files, and configuration XML files. Not the end of the world,
> >but annoying nonetheless.
> >
> >I'd also add to this benefit that users who are new to the project will
> >more easily be able to determine what version to put for a JIRA they want
> >to get committed to trunk. I've seen plenty of users who are confused by
> >having to set "0.24.0" as the version indicating trunk.
> >
> >There's also a nice symmetry in having the branch in svn/git (named trunk)
> >have the same name as the JIRA version indicator.
> My proposal was from a few months back related to the naming of versions
> in maven.
> It boils down to 'laziness is a virtue' + 'the maven version should match
> the branch'.
> Pick a name for a branch when you actually branch, not months before.
> 'trunk' in svn == 'trunk-SNAPSHOT' in maven == 'trunk' in JIRA.
> The creation of a branch should avoid impacting the place branched from
> (i.e. cause work for people on trunk because of a branch, or cause work
> for a branch due to a tag, etc).
> If the version in 'branch/2.0.x' has maven version '2.0.x-SNAPSHOT' and
> JIRA tag '2.0.0' then tagging 2.0.0 has the following steps:
> $> svn cp branch/2.0.x tags/2.0.0
> $> cd tags/2.0.0
> $> mvn versoins:set -DnewVersion=2.0.0
> $> svn diff   (spot check pom changes that versions:set did)
> $> mvn versions:commit
> $> svn commit
> The result is a new tag with the version set, and no changes to the branch
> that was tagged from.
> When the decision is made to have a 2.0.1, a jira tag can be made (or a
> 2.0.x tag renamed to 2.0.1, and a new 2.0.x tag made as Todd suggests).
> Being lazy here helps because maybe instead after some development on the
> 2.0.x branch it is decided to branch 2.1.x from it.
> When the decision to branch 2.1 occurs, a new branch 'branch/2.1.x' is
> made in svn, its version becomes '2.1.x-SNAPSHOT' and a JIRA tag for
> '2.1.x' is made or renamed from an old one.  The old 2.0.x branch is
> unchanged (and available for more minor bugfix releases).
> Once trunk or a branch is set up for build scripts or hudson, etc, it
> works without modification no matter how many times a branch or tag occurs
> off of it.
> >
> >
> >>
> >> Given the above I'd stick with 3.0.0 since it means lesser confusion and
> >> lesser work for the RM on future major releases.
> >>
> >
> >I honestly believe that this scheme is more confusing for devs and users,
> >and almost no different for RMs given what I described above with JIRA
> >version renaming. But, I don't feel super strongly about it. If this makes
> >sense to you, then I'll stop pushing.
> >
> >--
> >Aaron T. Myers
> >Software Engineer, Cloudera

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