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