On Mar 28, 2012, at 12:32 PM, Todd Lipcon wrote: > But new features also go to trunk. And if none of our new features are > incompatible, why do we anticipate that trunk is 3.0?
Essentially 'trunk' is where incompatible changes *may* be committed (in future). We should allow for that. I'm ambivalent about the 'version string' for trunk being either trunk-SNAPSHOT or 3.0.0-SNAPSHOT. 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. 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.) 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. On a related note: as I noted last night, I'd again urge committers to not set the 'fix-version' to trunk's version if it's committed to other branches (branch-1, branch-2 etc.) thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/
