[DISCUSS] Thinking about branch names
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
Re: [DISCUSS] Thinking about branch names
+1
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
>
Re: [DISCUSS] Thinking about branch names
+1 on having branches named for major release lines instead of specific
versions.
On Mon, Sep 22, 2014 at 8: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
>
--
Sean
Re: [DISCUSS] Thinking about branch names
+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 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
>
Re: [DISCUSS] Thinking about branch names
If you have a branch named 1.6, and you tag 1.6.1-RC1 from that branch, then do
you run the risk of someone committing something destined for 1.6.2 being
captured in a 1.6.1-RC2 tag? Do you want to prevent that? If so, how?
On my project we use a long running development branch, but when we are ready
for RC1 we branch for the release (e.g. release/1.6.1). All RC tags and
associated fixes are done on the release branch and merged back into the
development branch.
- Original Message -
From: "Josh Elser"
To: "dev"
Sent: Monday, September 22, 2014 11:18:12 PM
Subject: [DISCUSS] Thinking about branch names
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
Re: [DISCUSS] Thinking about branch names
+1
Using separate branches in this manner just adds complexity. I was
wondering myself why we needed to create separate branches when all we're
doing is tagging/deleting the already released ones. The only difference
between where one leaves off and another begins is the name of the branch.
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
> http://gravatar.com/ctubbsii
>
> 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
> >
>
Re: [DISCUSS] Thinking about branch names
+1
I also like Dave's suggestion of branching just in time for a release to
keep work on it isolated. That would be an appropriate action to take at
feature freeze.
On Tue, Sep 23, 2014 at 9:23 AM, Corey Nolet wrote:
> +1
>
> Using separate branches in this manner just adds complexity. I was
> wondering myself why we needed to create separate branches when all we're
> doing is tagging/deleting the already released ones. The only difference
> between where one leaves off and another begins is the name of the branch.
>
>
> 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
> > http://gravatar.com/ctubbsii
> >
> > 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
> > >
> >
>
--
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283
Re: [DISCUSS] Thinking about branch names
There are two cases I see here (RCx failed, and you want to RCx+1):
there were changes upstream and we want to include them all in the
next release candidate or there were changes upstream and we only want
some of them in the release candidate.
I highly anticipate the former to be the common case over the latter,
but some plan for the latter would be good. I can see benefit to
having a specific branch to isolate changes before an RC, but I could
also see cases where it's just more work for the person making the RC.
Ultimately, it's going to be some combination of merge or cherry-pick
on top of RCx to make RCx+1. Thus, I think it can be left to the
discretion of the person making the RC as to how they want to do it
rather than stress over it now and try to come up with "you must do
this" guidelines (again).
On Tue, Sep 23, 2014 at 9:33 AM, wrote:
>
> If you have a branch named 1.6, and you tag 1.6.1-RC1 from that branch, then
> do you run the risk of someone committing something destined for 1.6.2 being
> captured in a 1.6.1-RC2 tag? Do you want to prevent that? If so, how?
>
> On my project we use a long running development branch, but when we are ready
> for RC1 we branch for the release (e.g. release/1.6.1). All RC tags and
> associated fixes are done on the release branch and merged back into the
> development branch.
>
> - Original Message -
>
> From: "Josh Elser"
> To: "dev"
> Sent: Monday, September 22, 2014 11:18:12 PM
> Subject: [DISCUSS] Thinking about branch names
>
> 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
>
Re: [DISCUSS] Thinking about branch names
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
> http://gravatar.com/ctubbsii
>
> 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
>>
Re: [DISCUSS] Thinking about branch names
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?
>
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 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
> 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
> >>
>
Re: [DISCUSS] Thinking about branch names
I'm fine with the release manager selecting the branching strategy for a
release. A benefit to having a release branch is that it makes merges from
upstream after the branch is established explicit, so it's much less likely
any undesirable commit will sneak in (i.e., escape the notice of the
release manager).
Come to think of it, as soon as upstream gets one undesirable commit, a
release branch must be made. So another benefit is that people won't feel
like they need to hold off on commits just because a release is being put
together.
Still, I'm not stressing about it. It can certainly be a "guideline" or
"best practice", as with lots of other things.
On Tue, Sep 23, 2014 at 11:40 AM, Josh Elser wrote:
> There are two cases I see here (RCx failed, and you want to RCx+1):
> there were changes upstream and we want to include them all in the
> next release candidate or there were changes upstream and we only want
> some of them in the release candidate.
>
> I highly anticipate the former to be the common case over the latter,
> but some plan for the latter would be good. I can see benefit to
> having a specific branch to isolate changes before an RC, but I could
> also see cases where it's just more work for the person making the RC.
> Ultimately, it's going to be some combination of merge or cherry-pick
> on top of RCx to make RCx+1. Thus, I think it can be left to the
> discretion of the person making the RC as to how they want to do it
> rather than stress over it now and try to come up with "you must do
> this" guidelines (again).
>
> On Tue, Sep 23, 2014 at 9:33 AM, wrote:
> >
> > If you have a branch named 1.6, and you tag 1.6.1-RC1 from that branch,
> then do you run the risk of someone committing something destined for 1.6.2
> being captured in a 1.6.1-RC2 tag? Do you want to prevent that? If so, how?
> >
> > On my project we use a long running development branch, but when we are
> ready for RC1 we branch for the release (e.g. release/1.6.1). All RC tags
> and associated fixes are done on the release branch and merged back into
> the development branch.
> >
> > - Original Message -
> >
> > From: "Josh Elser"
> > To: "dev"
> > Sent: Monday, September 22, 2014 11:18:12 PM
> > Subject: [DISCUSS] Thinking about branch names
> >
> > 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
> >
>
--
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283
Re: [DISCUSS] Thinking about branch names
This is easily resolved if we're limiting fixes on these branches to
bugfixes, and not backporting features. If a fix makes it in the branch
before a RC, there's no reason it can't be evaluated for release, I'd
think. In these bugfix branches, we typically haven't had decisions about
whether to include a particular fix in the current bugfix release being
considered, or the next bugfix release. We typically have only made those
considerations for major versions.
That said, I think it's reasonable to branch first anyway. I typically do
this when I build a release candidate, because it's easier to blow away
that branch and any commits that the release plugin creates, if rejected.
It's also pretty easy to merge once approved.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Sep 23, 2014 at 9:33 AM, wrote:
>
> If you have a branch named 1.6, and you tag 1.6.1-RC1 from that branch,
> then do you run the risk of someone committing something destined for 1.6.2
> being captured in a 1.6.1-RC2 tag? Do you want to prevent that? If so, how?
>
> On my project we use a long running development branch, but when we are
> ready for RC1 we branch for the release (e.g. release/1.6.1). All RC tags
> and associated fixes are done on the release branch and merged back into
> the development branch.
>
> - Original Message -
>
> From: "Josh Elser"
> To: "dev"
> Sent: Monday, September 22, 2014 11:18:12 PM
> Subject: [DISCUSS] Thinking about branch names
>
> 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
>
>
Re: [DISCUSS] Thinking about branch names
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 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
> > http://gravatar.com/ctubbsii
> >
> > 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
> >>
>
Re: [DISCUSS] Thinking about branch names
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 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
http://gravatar.com/ctubbsii
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
Re: [DISCUSS] Thinking about branch names
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 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
>> 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
http://gravatar.com/ctubbsii
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
Re: [DISCUSS] Thinking about branch names
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 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
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
http://gravatar.com/ctubbsii
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
