[CRIU] Releases after 2.0

[Pavel Emelyanov]

On 02/17/2016 06:10 PM, Tycho Andersen wrote:
> On Wed, Feb 17, 2016 at 03:30:20PM +0300, Pavel Emelyanov wrote:
>> Hi, guys
>>
>> Some time ago I've raised a discussion about how to make new
>> criu releases. The main goal to achieve was to make it possible
>> to release newer stuff faster than once every 3 months.
>>
>> So, based on your feedback, let's try the new schedule since
>> the 7th or March (criu-2.0). Here's my proposal.
>>
>> First of all, time-driven releases are kept, dates would be
>> discussed (not to clash with holidays) and set in advance. For
>> now I propose to release every month, but the "first Monday" 
>> will definitely not work for January and May (hits New Year
>> and likely hits Labor or Victory day in Russia). Maybe some
>> day in the middle of the month? Will there be any problems 
>> with US/European holidays?
> 
> Missing a release is painful with the three month release cycle, but I
> think if the release is once/month, clash with holidays isn't too
> important since there will be another release soon. I think picking a
> day in the middle of the month will avoid New Year/Victory Day at the
> beginning and Thanksgiving/Christmas at the end of the month, but with
> a monthly cadence it's not super important (to me, at least :).

Heh :) OK, then we can make it "by the 15'th it should be there" and
then whenever there's a free^w WORKING day I make the release ;)
Hopefully I'll be able to predict those dates in advance by looking
at the calendar and wikipedia for the list of big holidays.

>> Next, there will be two branches -- stable and dev, all patches
>> get into dev first, then when we all agree that the feature is
>> OK (which in most of the cases includes having tests in zdtm
>> for one ;) and those tests pass) the patches are cherry-picked
>> into stable branch and get released in the closest release date.
>> The dev branch is then 'git rebase'-d onto new stable.
> 
> Why not just tag the new 2.x releases from -dev, no rebasing required?

Because -dev would be a collection of EVERYTHING in development we have,
likely this heap will not get stabilized ever :)

> I guess then you need a stable branch for each release instead, but it
> does mean you could release a 2.2.1 if there was some critical bug in
> that as well.

Yes, super-critical releases can (still) go out of order. I guess the
naming of the branches if misleading. Right now we have -stable branch(es)
that get created on demand and -(null) branch (master/head) that gets
tagged every 3 months and to which I commit stuff by default (and ask
for no-new-features two weeks before new tag).

The new scheme is -- current master branch is declared as "stable" (only
declared, branch name is still -(null)) and into it I cherry-pick patches
from -dev branch when we believe they've become good enough. And this branch
is tagged every month. New branch called -dev appears in which I commit
stuff from the mailing list by default (instead of committing them into
master as I do now). And since patches disappear from this branch from
time to time I will git rebase -dev onto fresh -(null) (master, new stable).

And what is now called -stable branches becomes ... hm ... urgent? that
gets released on demand once we have something really tempting and don't
want to wait for 4 more weeks.

-- Pavel