The way I've dealt with this on other projects in the past is the following:
1) RC1s for minor releases (e.g., 0.28.0-rc1, 0.29.0-rc1, 0.30-rc1, etc.)
are *always* tagged at some commit on the master branch.
This is only true for actual minor release (i.e. not point releases, e.g.
0.28.1, 0.28.2, etc.)
*0.28.0-rc1* ---> *0.29.0-rc1* ---> *0.30.0-rc1* ---> master
2) RC2s - RNns for minor releases (e.g. 0.28.0-rc2, 0.28.0-rc3
, 0.28.0-rc4
) can either be tagged from the master branch or along a branch originating
from an earlier release candidate.
0.28.0-rc1 --
----
-> master
\ \
\
\--->
*0.28.0-rc4*
\
\---> *0.28.0-rc2*
\
\---> *0.28.0-rc3*
3) Once an RC passes, a tag for the minor release is set as an alias for
the passing RC (.e.g 0.28.0-rc4 -> 0.28.0)
0.28.0-rc1 --
----
-> master
\ \
\
\---> 0.2
8
.0-rc
4 *(0.28.0)*
\
\---> 0.28.0-rc2
\
\---> 0.28.0-rc3
4) Any point releases that need to be made (e.g. 0.28.1, 0.28.2, etc.)
follow the same procedure, except that they don't originate from the master
branch, but rather the tag set for the previous point release.
--
----
-> master
\
\---> 0.2
8
.0-rc
4 (0.28.0)
\
\-----> *0.28.1-rc1*
* \*
* \---> 0.28.1-rc2 (0.28.1)*
* \*
* \---> 0.28.2-rc1 (0.28.2)*
This way it's easy to track the full set of release candidates, as well as
how they relate to previous release candidates, minor releases, and point
releases.
In the past, I've never worried about publishing the branches behind these
tags while building out the RCs, but I see no reason why that should be a
problem. To avoid confusion, we could name them e.g., 0.28.0-rc4-dev and
then grow/shrink them as necessary until we are satisfied with announcing
the RC. At that point, the branch should be dropped and the tag set as e.g.,
0.28.0-rc4.
On Tue, Mar 22, 2016 at 3:40 AM, Joris Van Remoortere <jo...@apache.org>
wrote:
> +1 for branch per RC (if we go with branches). I like your argument against
> re-writing history if we make a mistake.
>
> I think the 2 issues that have come up are:
> 1) visibility into the release process
> 2) pain / lack of context for the release manager of backports to resolve
> merge conflicts for bugs
>
> For 2), Jie's suggestion was that if we had branches set up for future
> backports (even if it were something like 0.24.2-WIP) then committers would
> both:
> a) help amortize the cost of cherry-picking / merge conflicts
> b) have current context about the patch when considering whether it is a
> critical bug fix, as well as backwards compatible
>
> These are likely issues that Vinod will also address in his 1.0 and LTS
> proposals.
>
> On Mon, Mar 21, 2016 at 1:52 PM, Benjamin Mahler <bmah...@apache.org>
> wrote:
>
> > A single branch for a release seems brittle because it assumes that RC
> tag
> > N shares the same lineage as RC tag N-1. This is mostly true, but not
> > always. The branching approach that would mirror how I've put together
> > releases would be to have a branch for each RC. The RC N branch is
> usually
> > on top of the RC N-1 branch, but not always.
> >
> > This allows both of the following scenarios:
> >
> > (1)
> > master --------> RC1 ---------> RC2
> >
> > (2)
> > master --------> RC1
> > \--------> RC2
> >
> > Scenario (2) is not possible with a single release branch. The other nice
> > thing about 1 branch per RC is that if we make mistakes, we just create a
> > new branch, rather than re-write history or push out branch removals.
> > Also, we should avoid naming the branch exactly the same as the tag, as
> > that will lead to confusion.
> >
> > But my thought here is that we should take a step back and look at what
> > problems we want to solve with the current tag-only approach. Joris and
> Jie
> > seem to be hinting at there being a lack of visibility into the progress
> of
> > RCs. Is that the issue we're trying to solve? Collaboration on RC's? I
> > haven't done a release in quite some time so it would be great to
> > understand the current pain points.
> >
> > On Mon, Mar 21, 2016 at 1:20 AM, Joris Van Remoortere <jo...@apache.org>
> > wrote:
> >
> > > The SHAs rarely exist on HEAD because we tend to cherry-pick bug fixes
> > into
> > > release candidates.
> > >
> > > I'm all for using branches in the repository to put together the
> release
> > > candidates, as well as have committers consider their bug fixes for
> some
> > N
> > > number of backport (future LTS) releases.
> > >
> > > As Kevin and Michael mentioned, tags and branches are different
> concepts.
> > > We can use them together. We still want to create immutable tags to
> point
> > > at releases so that we don't accidentally add new patches to releases
> by
> > > updating a branch.
> > >
> > > I think building up the releases in public branches is a good step
> > towards
> > > improved visibility. I hope this will also increase the accountability
> of
> > > the community to ensure the patches they contribute are committed to
> the
> > > right branches.
> > >
> > > On Fri, Mar 18, 2016 at 8:10 PM, Erik Weathers <
> > > eweath...@groupon.com.invalid> wrote:
> > >
> > > > BTW, if the tag is created against a commit that *doesn't* become
> > > > "unreachable" from HEAD [1], then `git pull` is sufficient to also
> pull
> > > > down the tags.
> > > >
> > > > The only time I've needed to do `git fetch --tags` is when the tagged
> > > > commit SHA gets merged away. So presumably the process being
> followed
> > by
> > > > the core committers / releasers is resulting in these "unreachable"
> > tags.
> > > > Not sure if that is preventable though.
> > > >
> > > > - Erik
> > > >
> > > > [1]
> > > http://eddiemoya.com/2013/02/21/better-git-git-fetch-not-getting-tags/
> > > >
> > > > From the git manual (“git help fetch”): [1]
> > > >
> > > > -t, –tags Most of the tags are fetched automatically as branch heads
> > are
> > > > downloaded, but tags that do not point at objects reachable from the
> > > branch
> > > > heads that are being tracked will not be fetched by this mechanism.
> > This
> > > > flag lets all tags and their associated objects be downloaded. The
> > > default
> > > > behavior for a remote may be specified with the remote.<name>.tagopt
> > > > setting. See git-config(1).
> > > >
> > > >
> > > >
> > > > On Fri, Mar 18, 2016 at 6:22 PM, Michael Browning <
> > > invitapri...@gmail.com>
> > > > wrote:
> > > >
> > > > > I agree with Kevin -- tags are immutable, so they're naturally
> suited
> > > > > for labeling releases, which ought to be immutable too.
> > > > >
> > > > > On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues <klue...@gmail.com>
> > > wrote:
> > > > > > I respectfully disagree.
> > > > > >
> > > > > > The whole purpose of tags is to mark permanent things like
> > releases,
> > > > > > whereas branches are designed as temporary lines of development
> > that
> > > > > > come and go (and grow and shrink) dynamically all the time.
> > > > > >
> > > > > > On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu <yujie....@gmail.com>
> > wrote:
> > > > > >> I like the idea of using branches to manage releases.
> > > > > >>
> > > > > >> We can use that to manage point releases and backports as well.
> > > > > >>
> > > > > >> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag
> RCs
> > > in
> > > > > that
> > > > > >> branch. Once the RC is accepted, the head of that branch will
> > become
> > > > the
> > > > > >> release.
> > > > > >>
> > > > > >> Then, we immediate fork that branch and create 0.29.1 branch.
> > > > > >>
> > > > > >> When a new bug fix is committed on the trunk, the committer will
> > > > decide
> > > > > >> whether it'll affect the old releases (a bounded number, we can
> > > decide
> > > > > that
> > > > > >> later). If it does, the committer of that patch should also
> > > > cherry-pick
> > > > > >> that patch to the point releases (e.g., 0.29.1 in this case). We
> > can
> > > > do
> > > > > a
> > > > > >> timely based point releases.
> > > > > >>
> > > > > >> - Jie
> > > > > >>
> > > > > >> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <
> > cw...@twopensource.com>
> > > > > wrote:
> > > > > >>
> > > > > >>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <
> > jos...@mesosphere.io>
> > > > > wrote:
> > > > > >>> > Cong Wang,
> > > > > >>> >
> > > > > >>> > The tags are sync'd. See:
> > > > https://github.com/apache/mesos/releases
> > > > > >>> >
> > > > > >>> > You might not have done: git pull --tags
> > > > > >>>
> > > > > >>>
> > > > > >>> Yeah, I figured it out by myself too. This is why I hate tags
> > > > > personally,
> > > > > >>> branches are better since they are fetched without additional
> > > > > parameters.
> > > > > >>>
> > > > > >>> Any reason why Mesos maintainers picked tags over branches to
> > > manage
> > > > > >>> releases? Just curious...
> > > > > >>>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ~Kevin
> > > > >
> > > >
> > >
> >
>
--
~Kevin
