Todd Lipcon 2012-03-28, 18:53
Aaron T. Myers 2012-03-28, 18:59
Todd Lipcon 2012-03-28, 19:02
Owen OMalley 2012-03-28, 19:25
Todd Lipcon 2012-03-28, 19:32
Owen OMalley 2012-03-28, 19:39
Doug Cutting 2012-03-29, 00:11
Aaron T. Myers 2012-03-28, 23:11
Arun C Murthy 2012-03-28, 20:57
Aaron T. Myers 2012-03-28, 21:14
Arun C Murthy 2012-03-28, 23:00
Scott Carey 2012-03-29, 19:45
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
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]>
> >> 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
> >> 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
> >> 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
> >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
> >> 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.
Milind.Bhandarkar@... 2012-04-03, 18:27
Aaron T. Myers 2012-04-03, 20:58
Milind.Bhandarkar@... 2012-04-03, 21:37
Aaron T. Myers 2012-04-03, 21:44
Milind.Bhandarkar@... 2012-04-03, 22:14
Aaron T. Myers 2012-04-03, 22:21
Milind.Bhandarkar@... 2012-04-03, 22:24
Steve Loughran 2012-04-12, 16:32
Todd Lipcon 2012-04-12, 17:27
Robert Evans 2012-04-12, 18:19