Another point to consider here is that many projects (such as guava) omit ".0" suffixes on versions (releasing, for instance 11, followed by 11.0.1 and 11.0.2 for bugfixes).
It's probably not a big deal. It's only a slight risk of confusion, and SCM is not for users, it's for devs, so I'm fine with the succinctness, as long as we don't ever create tags with the same names. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Sep 23, 2014 at 11:45 AM, Josh Elser <josh.el...@gmail.com> wrote: > Personally, I like the succinctness of "1.5" over the ones you > presented. I don't feel like "1.5.x" or "1.5-dev" tell me anything > more than "1.5" already did so they just turn into more typing. I > don't really think there's a high chance that we ever abandon x.y.z > version strings, so there isn't a big chance for it to look like a > release. > > For context, Hadoop (and other related projects) tend to do a > "branch-X" and "branch-X.Y". For the same reasons as above, I feel > like the "branch-" is unnecessary. > > Is anyone else concerned about potential confusion having "x.y" branch > names? > > On Tue, Sep 23, 2014 at 9:04 AM, Christopher <ctubb...@apache.org> wrote: > > +1 to static dev branch names per release series. (this would also fix > the > > Jenkins spam when the builds break due to branch name changes) > > > > However, I kind of prefer 1.5.x or 1.5-dev, or similar, over simply 1.5, > > which looks so much like a release version that I wouldn't want it to > > generate any confusion. > > > > Also, for reference, here's a few git commands that might help some > people > > avoid the situation that happened: > > git remote update > > git remote prune $(git remote) > > git config --global push.default current # git < 1.8 > > git config --global push.default simple # git >= 1.8 > > > > The situation seems to primarily have occurred because of some pushes > that > > succeeded because the local clone was not aware that the remote branches > > had disappeared. Pruning will clean those up, so that you'll get an error > > if you try to push. Simple/current push strategy will ensure you don't > push > > all matching branches by default. Josh's proposed solution makes it less > > likely the branches will disappear/change on a remote, but these are > still > > useful git commands to be aware of, and are related enough to this > > situation, I thought I'd share. > > > > > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > On Mon, Sep 22, 2014 at 11:18 PM, Josh Elser <josh.el...@gmail.com> > wrote: > > > >> After working on 1.5.2 and today's branch snafu, I think I've come to > the > >> conclusion that our branch naming is more pain than it's worth (I > believe I > >> was the one who primarily argued for branch names as they are current > >> implemented, so take that as you want). > >> > >> * Trying to making a new branch for the "next" version as a release is > >> happening forces you to fight with Maven. Maven expects that your > "next" is > >> going to be on the same branch and the way it makes commits and bumps > >> versions for you encourages this. Using a new branch for "next" is more > >> manual work for the release manager. > >> > >> * The time after we make a release, there's a bit of confusion (I do it > >> too, just not publicly... yet) about "what branch do I put this fix for > >> _version_ in?". It's not uncommon to put it in the "old" branch instead > of > >> the new one. The problem arises when the old branch has already been > >> deleted. If a developer has an old version of that branch, there's > nothing > >> to tell them "hey, your copy of this branch is behind the remote's copy > of > >> this branch. I'm not accepting your push!" Having a single branch for a > >> release line removes this hassle. > >> > >> "Pictorially", I'm thinking we would change from the active branches > >> {1.5.3-SNAPSHOT, 1.6.1-SNAPSHOT, 1.6.2-SNAPSHOT, master} to {1.5, 1.6, > >> master}. (where a git tag would exist for the 1.6.1 RCs). > >> > >> IIRC, the big argument for per-release branches was of encouraging > >> frequent, targeted branches (I know the changes for this version go in > this > >> branch). I think most of this can be mitigated by keeping up with > frequent > >> releases and coordination with the individual cutting the release. > >> > >> In short, I'm of the opinion that I think we should drop the > ".z-SNAPSHOT" > >> suffix from branch names (e.g. 1.5.3-SNAPSHOT) and move to a shorter > "x.y" > >> (e.g. 1.5) that exists for the lifetime of that version. I think we > could > >> also use this approach if/when we change our versioning to start using > the > >> "x" component of "x.y.z". > >> > >> Thoughts? > >> > >> - Josh > >> >
