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 <sc...@richrelevance.com>wrote: > > > 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 > >
