+1 I also like Dave's suggestion of branching just in time for a release to keep work on it isolated. That would be an appropriate action to take at feature freeze.
On Tue, Sep 23, 2014 at 9:23 AM, Corey Nolet <[email protected]> wrote: > +1 > > Using separate branches in this manner just adds complexity. I was > wondering myself why we needed to create separate branches when all we're > doing is tagging/deleting the already released ones. The only difference > between where one leaves off and another begins is the name of the branch. > > > 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 > > > > > > -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
