hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun C Murthy <...@hortonworks.com>
Subject Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Date Wed, 28 Mar 2012 20:57:24 GMT

On Mar 28, 2012, at 12:32 PM, Todd Lipcon wrote:

> But new features also go to trunk. And if none of our new features are
> incompatible, why do we anticipate that trunk is 3.0?

Essentially 'trunk' is where incompatible changes *may* be committed (in future). We should
allow for that.

I'm ambivalent about the 'version string' for trunk being either trunk-SNAPSHOT or 3.0.0-SNAPSHOT.

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.

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.)

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.

On a related note: as I noted last night, I'd again urge committers to not set the 'fix-version'
to trunk's version if it's committed to other branches (branch-1, branch-2 etc.)


Arun C. Murthy
Hortonworks Inc.

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