accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [DISCUSS] Thinking about branch names
Date Tue, 23 Sep 2014 15:45:46 GMT
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 <ctubbsii@apache.org> 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 <josh.elser@gmail.com> 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
>>

Mime
View raw message