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