[CRIU] Releases after 2.0
Tycho Andersen
tycho.andersen at canonical.com
Wed Feb 17 07:10:21 PST 2016
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 :).
> 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?
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.
Tycho
> With this I will likely need the feature owner to point out the
> necessary patches and help with porting them.
>
> Also, as a side effect git pull on dev branch will effectively
> recreate the whole branch after releases since the branch would
> get renewed. Hope this is OK.
>
> -- Pavel
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
More information about the CRIU
mailing list