Home | About | Sematext search-lucene.com search-hadoop.com
 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
Aaron T. Myers 2012-03-28, 21:14
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.
>
> 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