Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
MapReduce >> mail # dev >> Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x


Copy link to this message
-
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
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 <[EMAIL PROTECTED]>wrote:

>
>
> On 3/28/12 2:14 PM, "Aaron T. Myers" <[EMAIL PROTECTED]> wrote:
>
> >On Wed, Mar 28, 2012 at 1:57 PM, Arun C Murthy <[EMAIL PROTECTED]>
> >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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB