Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of josh.elser@gmail.com designates
 209.85.216.52 as permitted sender)
Message-ID: <5425C88B.2050607@gmail.com>
Date: Fri, 26 Sep 2014 16:11:55 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Thinking about branch names
References: <5420E674.9010909@gmail.com>
 <CAL5zq9ZRa_1V5nf5k5F6qMjcdANm6VebQNiK6gwDKEyp7Lterw@mail.gmail.com>
 <CAOyNEs7ZOJ9FEhA1ZyKRv4EJTHn+Yrrj1h_v_VNDoCyBnDmaHA@mail.gmail.com>
 <CAL5zq9YXG2U74dST9uGA9z5gTPfEcRzBbdnjadS1U+Fkt5-fHw@mail.gmail.com>
 <5422560B.4030806@gmail.com>
 <CAL5zq9bF4h=gbxBUppc0cd+Pf66deuFTS3nu47h38QU0GOhifQ@mail.gmail.com>
In-Reply-To: 
 <CAL5zq9bF4h=gbxBUppc0cd+Pf66deuFTS3nu47h38QU0GOhifQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Yes, I will do so. Thanks for your feedback everyone. I'll try to update the documentation as well.

Christopher wrote:
> I see lots of +1s on this thread, and no -1s. There seems to be a lot of
> consensus. Josh, do you want to go ahead and make this change?
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Wed, Sep 24, 2014 at 1:26 AM, Josh Elser<josh.elser@gmail.com>  wrote:
>
>> 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
>>> http://gravatar.com/ctubbsii
>>>
>>> On Tue, Sep 23, 2014 at 11:45 AM, Josh Elser<josh.elser@gmail.com>
>>> 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<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
>>>>>>
>>>>>>
>