I see lots of +1s on this thread, and no -1s. There seems to be a lot of consensus. Josh, do you want to go ahead and make this change?
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Sep 24, 2014 at 1:26 AM, Josh Elser <[email protected]> wrote: > Good point, Christopher. I didn't really consider projects outside of the > Hadoop ecosystem. As long as we're cognizant (if our versioning strings do > get "better" moving forward), I think this shouldn't be an issue. Hold me > honest :) > > > Christopher wrote: > >> 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<[email protected]> >> 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<[email protected]> >>> 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<[email protected]> >>>> >>> 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 >>>>> >>>>> >>
