accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <>
Subject Re: [DISCUSS] Thinking about branch names
Date Tue, 23 Sep 2014 12:44:34 GMT

On Mon, Sep 22, 2014 at 10:18 PM, Josh Elser <> 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

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