accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [DISCUSS] Thinking about branch names
Date Wed, 24 Sep 2014 05:26:35 GMT
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
> On Tue, Sep 23, 2014 at 11:45 AM, Josh Elser<>  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<>  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
>>> On Mon, Sep 22, 2014 at 11: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

View raw message