[CRIU] [RFC] Future CRIU releases

[Saied Kazemi]

I also agree that having fixed dates for stable releases is good and we
should continue doing it.

Regarding faster access to newly implemented features, how about a separate
"channel" called beta or dev that releases weekly (or at will)?  New
features are introduced in this channel and, after they've been qualified
for a few weeks, move to the stable channel.  This is like what OS distros
such as CoreOS do (they actually have three channels: alpha, beta, stable;
visit https://coreos.com/releases/).

--Saied


On Thu, Dec 17, 2015 at 8:51 AM, Tycho Andersen <
tycho.andersen at canonical.com> wrote:

> On Thu, Dec 17, 2015 at 03:23:32PM +0300, Pavel Emelyanov wrote:
> > Hi,
> >
> > We've been playing the time-driven releases model for the past
> > year and, at some sense, succeeded. However, it seems like the
> > strict dates that were chosen were not 100% comfortable for all
> > the parties.
> >
> > Also there sometimes appeared the need to have some "quite new"
> > functionality early (or -- during the one week feature freeze
> > period) and waiting till the next release was also not nice.
> >
> > So this e-mail is a call for comments -- shall we continue the
> > once-a-season releases as we do now, should we slightly fix it
> > (e.g. by formalizing the -stable branches) or should we change
> > it completely?
>
> I like the fixed date release because it forces us to release stuff.
> My experience is that everyone wants to wait for "one more bug fix" if
> we don't have a timed release.
>
> One solution to the "wait for next release" problem is just to release
> more often, once every 1-2 months maybe instead of once every three
> months? Of course, it's easy for me to suggest this since I don't have
> to do any work maintaining releases :)
>
> Another option would be to adjust the dates slightly, say Feb 1, May
> 1, August 1, Nov 1, which would perhaps align (or not align) with
> holidays slightly better.
>
> Tycho
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20151217/4ffeff44/attachment.html>