[CRIU] CRIU release schedule proposal

[Kir Kolyshkin]

Pavel,

You asked me to share my view on how to produce CRIU releases.

Basically there can be two strategies: feature-driven and time-driven.
Most software projects that don't do a lot of planning make feature-driven
releases, and it seems natural and logical. But there are a few bad things
about it, which can be brought down to these two things:

1. Next release time is not predictable by users. It can happen in a week,
in a month, or in a year.

2. A release can be delayed for a long time because a new feature
might seem not polished enough.

CRIU release process was free of such deficiencies because its releases
were tied to appropriate kernel releases adding new features needed for 
CRIU.

As this is no longer the case, there's no reason to be tied to kernel 
releases,
but there is a need to have some other scheme.

My simple suggestion is to target for 3-4 releases a year, in other words,
having a "relaxed quarterly" release schedule -- plan for a release each 3
months, but it's OK if a release will be delayed by up to a month.

Another thing I'd like to add. From my experience, rc releases make little
sense, as no one uses those. What makes sense is hotfixes -- once you
made a release, you should be ready to fix regressions and critical bugs
quickly, and to release a hot fix update within days if needed. Again,
nothing new here, this is essentially a model used by the Linux kernel
(although you don't have to support older releases for now, I guess,
just a latest one).

Hope that makes sense.

Kir.