accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Thinking about branch names
Date Wed, 24 Sep 2014 05:13:17 GMT
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, <dlmarion@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.elser@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message