accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [DISCUSS] Thinking about branch names
Date Tue, 23 Sep 2014 13:33:31 GMT

If you have a branch named 1.6, and you tag 1.6.1-RC1 from that branch, then do you run the
risk of someone committing something destined for 1.6.2 being captured in a 1.6.1-RC2 tag?
Do you want to prevent that? If so, how? 

On my project we use a long running development branch, but when we are ready for RC1 we branch
for the release (e.g. release/1.6.1). All RC tags and associated fixes are done on the release
branch and merged back into the development branch. 

----- Original Message -----

From: "Josh Elser" <> 
To: "dev" <> 
Sent: Monday, September 22, 2014 11:18:12 PM 
Subject: [DISCUSS] Thinking about branch names 

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


- Josh 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message