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 <josh.el...@gmail.com> 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, <dlmar...@comcast.net> 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" <josh.el...@gmail.com>
> > To: "dev" <dev@accumulo.apache.org>
> > 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
