Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAOyNEs7ZOJ9FEhA1ZyKRv4EJTHn+Yrrj1h_v_VNDoCyBnDmaHA@mail.gmail.com>
References: <5420E674.9010909@gmail.com>
	<CAL5zq9ZRa_1V5nf5k5F6qMjcdANm6VebQNiK6gwDKEyp7Lterw@mail.gmail.com>
	<CAOyNEs7ZOJ9FEhA1ZyKRv4EJTHn+Yrrj1h_v_VNDoCyBnDmaHA@mail.gmail.com>
Date: Tue, 23 Sep 2014 12:03:16 -0400
Message-ID: 
 <CAGUtCHq6q9B8g+JOO58S9uWo8xxdjk=VeXdaD6ZHhpsDhGvxFA@mail.gmail.com>
Subject: Re: [DISCUSS] Thinking about branch names
From: Keith Turner <keith@deenlo.com>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a1133a0fe8d407d0503bdb47a

--001a1133a0fe8d407d0503bdb47a
Content-Type: text/plain; charset=UTF-8

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?
>

I am not.  I would be if there was something in the way that git worked
that made this choice confusing.  When I checkout a tag, git prints out
tome about being in detached HEAD state, thats fairly obvious.  In there
anything else that may be confusing w/ the way git works w/ these tag 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
> >>
>

--001a1133a0fe8d407d0503bdb47a--