You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myriad.apache.org by Santosh Marella <sm...@maprtech.com> on 2015/11/30 21:42:33 UTC
Merges to Myriad master branch
Hello All,
As we are in the middle of IPMC voting to release myriad-0.1.0, I request
the committers to hold off merging any *major* PRs to the "master" branch.
The current RC has been tested well for the features that went into it.
Just in case we receive more feedback from IPMC, we want the "master"
branch to stay as close to current RC as possible so that when we cut a new
RC with IPMC's feedback, we don't need to worry too much about the
stability of the new RC.
Thanks,
Santosh
Re: Merges to Myriad master branch
Posted by Adam Bordelon <ad...@mesosphere.io>.
Same tag approach works for 0.1.1 too.
git checkout 0.1.0 (we'd tag the official 0.1.0 release too)
git cherry-pick ...
git tag 0.1.1-rc1
git push --tags
Of course, I'm not mandating this, just proposing an option based on how
Mesos does it.
On Tue, Dec 1, 2015 at 8:59 AM, Darin Johnson <db...@gmail.com>
wrote:
> I like Adam's idea for RCs, but I also really like the idea of a 0.1.0
> branch for bug fixes. That way we can cut a 0.1.1 maintenance release much
> easier than trying to cut off master. Seems like a lot of apache projects
> handle it that way.
>
> Darin
>
> Otherwise there will likely be some really ugly merges.
> On Mon, Nov 30, 2015 at 1:49 PM, Adam Bordelon <ad...@mesosphere.io> wrote:
>
> > Sounds like a code freeze/thaw. What are the conditions for a *major* PR?
> > Even a minor PR could introduce major bugs.
> > I will point out that you have the option of cherry-picking specific new
> > patches on top of the 0.1.0-rc3 tag to create a new rc. This ensures that
> > 0.1.0 only includes changes that were tested in the previous rc's plus
> > specific critical fixes. This is how Mesos handles patch releases (e.g.
> > 0.23.0 -> 0.23.1) or release candidates after the first. Cut the rc0/1
> from
> > HEAD, then cherry-pick on top for all future rcs.
> >
> >
> >
> >
> Do you mean cherry-pick into branches (e.g. 0.1.x branch) instead of tag
> which is supposed to be immutable ? Having a branch also enables future
> releases based on 0.1.0 release.
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: Merges to Myriad master branch
Posted by Darin Johnson <db...@gmail.com>.
I like Adam's idea for RCs, but I also really like the idea of a 0.1.0
branch for bug fixes. That way we can cut a 0.1.1 maintenance release much
easier than trying to cut off master. Seems like a lot of apache projects
handle it that way.
Darin
Otherwise there will likely be some really ugly merges.
On Mon, Nov 30, 2015 at 1:49 PM, Adam Bordelon <ad...@mesosphere.io> wrote:
> Sounds like a code freeze/thaw. What are the conditions for a *major* PR?
> Even a minor PR could introduce major bugs.
> I will point out that you have the option of cherry-picking specific new
> patches on top of the 0.1.0-rc3 tag to create a new rc. This ensures that
> 0.1.0 only includes changes that were tested in the previous rc's plus
> specific critical fixes. This is how Mesos handles patch releases (e.g.
> 0.23.0 -> 0.23.1) or release candidates after the first. Cut the rc0/1
from
> HEAD, then cherry-pick on top for all future rcs.
>
>
>
>
Do you mean cherry-pick into branches (e.g. 0.1.x branch) instead of tag
which is supposed to be immutable ? Having a branch also enables future
releases based on 0.1.0 release.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Merges to Myriad master branch
Posted by Adam Bordelon <ad...@mesosphere.io>.
For some reason, Mesos only uses tags, not branches, presumably because we
don't want to have to manage merging between a feature/release branches.
Everything goes into master, so we tag an rc1 from master, cherry-pick on
top of that, then tag an rc2.
git checkout 0.1.0-rc1 (checks out the tag, not a branch)
git cherry-pick deadbeef facebead ...
git tag 0.1.0-rc2
git push --tags
Myriad could certainly do it differently, but we shouldn't be cutting rc's
from master after the first one. It should either go into a 0.1.0-rc? set
of tags, or a 0.1.x branch. Then a follow-up 0.1.1 could be based on the
tag/branch, but a 0.2.0-rc1 would be a new cut from master.
On Mon, Nov 30, 2015 at 4:10 PM, Luciano Resende <lu...@gmail.com>
wrote:
> On Mon, Nov 30, 2015 at 1:49 PM, Adam Bordelon <ad...@mesosphere.io> wrote:
>
> > Sounds like a code freeze/thaw. What are the conditions for a *major* PR?
> > Even a minor PR could introduce major bugs.
> > I will point out that you have the option of cherry-picking specific new
> > patches on top of the 0.1.0-rc3 tag to create a new rc. This ensures that
> > 0.1.0 only includes changes that were tested in the previous rc's plus
> > specific critical fixes. This is how Mesos handles patch releases (e.g.
> > 0.23.0 -> 0.23.1) or release candidates after the first. Cut the rc0/1
> from
> > HEAD, then cherry-pick on top for all future rcs.
> >
> >
> >
> >
> Do you mean cherry-pick into branches (e.g. 0.1.x branch) instead of tag
> which is supposed to be immutable ? Having a branch also enables future
> releases based on 0.1.0 release.
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: Merges to Myriad master branch
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Nov 30, 2015 at 1:49 PM, Adam Bordelon <ad...@mesosphere.io> wrote:
> Sounds like a code freeze/thaw. What are the conditions for a *major* PR?
> Even a minor PR could introduce major bugs.
> I will point out that you have the option of cherry-picking specific new
> patches on top of the 0.1.0-rc3 tag to create a new rc. This ensures that
> 0.1.0 only includes changes that were tested in the previous rc's plus
> specific critical fixes. This is how Mesos handles patch releases (e.g.
> 0.23.0 -> 0.23.1) or release candidates after the first. Cut the rc0/1 from
> HEAD, then cherry-pick on top for all future rcs.
>
>
>
>
Do you mean cherry-pick into branches (e.g. 0.1.x branch) instead of tag
which is supposed to be immutable ? Having a branch also enables future
releases based on 0.1.0 release.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Merges to Myriad master branch
Posted by Santosh Marella <sm...@maprtech.com>.
Thanks Adam. If there is a way to cherry pick and apply commits to tags (as
opposed to branches), we should probably do that. I will read more about it.
Santosh
On Mon, Nov 30, 2015 at 1:49 PM, Adam Bordelon <ad...@mesosphere.io> wrote:
> Sounds like a code freeze/thaw. What are the conditions for a *major* PR?
> Even a minor PR could introduce major bugs.
> I will point out that you have the option of cherry-picking specific new
> patches on top of the 0.1.0-rc3 tag to create a new rc. This ensures that
> 0.1.0 only includes changes that were tested in the previous rc's plus
> specific critical fixes. This is how Mesos handles patch releases (e.g.
> 0.23.0 -> 0.23.1) or release candidates after the first. Cut the rc0/1 from
> HEAD, then cherry-pick on top for all future rcs.
>
> On Mon, Nov 30, 2015 at 12:42 PM, Santosh Marella <sm...@maprtech.com>
> wrote:
>
> > Hello All,
> >
> > As we are in the middle of IPMC voting to release myriad-0.1.0, I
> request
> > the committers to hold off merging any *major* PRs to the "master"
> branch.
> >
> > The current RC has been tested well for the features that went into it.
> > Just in case we receive more feedback from IPMC, we want the "master"
> > branch to stay as close to current RC as possible so that when we cut a
> new
> > RC with IPMC's feedback, we don't need to worry too much about the
> > stability of the new RC.
> >
> > Thanks,
> > Santosh
> >
>
Re: Merges to Myriad master branch
Posted by Adam Bordelon <ad...@mesosphere.io>.
Sounds like a code freeze/thaw. What are the conditions for a *major* PR?
Even a minor PR could introduce major bugs.
I will point out that you have the option of cherry-picking specific new
patches on top of the 0.1.0-rc3 tag to create a new rc. This ensures that
0.1.0 only includes changes that were tested in the previous rc's plus
specific critical fixes. This is how Mesos handles patch releases (e.g.
0.23.0 -> 0.23.1) or release candidates after the first. Cut the rc0/1 from
HEAD, then cherry-pick on top for all future rcs.
On Mon, Nov 30, 2015 at 12:42 PM, Santosh Marella <sm...@maprtech.com>
wrote:
> Hello All,
>
> As we are in the middle of IPMC voting to release myriad-0.1.0, I request
> the committers to hold off merging any *major* PRs to the "master" branch.
>
> The current RC has been tested well for the features that went into it.
> Just in case we receive more feedback from IPMC, we want the "master"
> branch to stay as close to current RC as possible so that when we cut a new
> RC with IPMC's feedback, we don't need to worry too much about the
> stability of the new RC.
>
> Thanks,
> Santosh
>