On 3/28/12 2:14 PM, "Aaron T. Myers" <a...@cloudera.com> wrote:
>On Wed, Mar 28, 2012 at 1:57 PM, Arun C Murthy <a...@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
