<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 10:12 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/18/2015 08:43 PM, Saied Kazemi wrote:<br>
<span class="">> On Fri, Dec 18, 2015 at 9:05 AM, Pavel Emelyanov <<a href="mailto:xemul@parallels.com">xemul@parallels.com</a> <mailto:<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>>> wrote:<br>
><br>
> On 12/17/2015 09:18 PM, Saied Kazemi wrote:<br>
> > I also agree that having fixed dates for stable releases is good and we<br>
> > should continue doing it.<br>
><br>
> OK :)<br>
><br>
> > Regarding faster access to newly implemented features, how about a separate<br>
> > "channel" called beta or dev that releases weekly (or at will)? New features<br>
> > are introduced in this channel and, after they've been qualified for a few<br>
> > weeks, move to the stable channel. This is like what OS distros such as<br>
> > CoreOS do (they actually have three channels: alpha, beta, stable; visit<br>
> > <a href="https://coreos.com/releases/" rel="noreferrer" target="_blank">https://coreos.com/releases/</a>).<br>
><br>
> Hm... Do you know whether they do those releases from one repo, or constantly<br>
> move only the good stuff from alfa to beta and then to stable?<br>
><br>
><br>
> I'm pretty sure all releases come from the same repo, but different branches. New<br>
> features are committed to master and then cherry picked onto alpha, beta, and stable.<br>
<br>
</span>Ah, I see. My question was whether they just tag master branch with next alfa/bete<br>
release and after stabilization period tag the stable one, but now it's clear that<br>
they migrate features between branches.<br>
<span class=""><br>
> Does a two-branch scheme (dev and stable) work for CRIU?<br>
<br>
</span>That's a good question which I'm trying to figure out :) So far I've seen that it<br>
was not that easy to distinguish one feature from another in terms of commit IDs,<br>
so cherry-picking a feature from master/dev branch into stable one would be quite<br>
a challenge.<br>
<br>
Back-porting the tempting stuff from HEAD to "v1.${latest}-stable" branch could be<br>
done with the help of feature owner, though.<br></blockquote><div><br></div><div>I'm not a release engineering expert, so this is just a suggestion. There are two ways to go. One would be to create the dev and stable branches, keep them forever, cherry pick onto them, and tag milestones in those branches. The other would be to create a dev branch that gets promoted (renamed) to the stable branch after qualification period. The old stable branch can be deleted or renamed and frozen.</div><div><br></div><div>This way you'd minimize the task of cherry picking because each time you create a new dev branch from master, it includes all the commits up to that point. Cherry picking onto the stable branch should generally be avoided unless there is a major security patch.</div><div><br></div><div>--Saied</div><div><br></div></div></div></div>