[Nix-dev] Stable NixOS releases

phreedom at yandex.ru phreedom at yandex.ru
Tue May 14 15:44:24 CEST 2013


On Вторник 14 мая 2013 14:25:46 Mathijs Kwik wrote:
> Wow, (y)our little distro is growing up so fast :')
> Congrats on reaching the point where the user base has become large enough
> and is running serious production stuff on it, mandating a stable
> channel.

It isn't only about production. I'm sure that we managed to scare away some 
newbie users with a temporarily broken master branch.

> I would prefer a 3 months cycle.
> 6 months is quite long, making upgrades (possibly) harder to do.
> Also, we probably want releases to be backward compatible 1 release
> (regarding configuration.nix and nix features), so a long cycle might
> complicate things or hold back master development.

We should try shorter release cycles first, because we have no idea how much 
effort it is going to take and managing a recent stable branch is somewhat 
easier since it would probably need much less backports and backports would be 
easier, mostly cherry-picks.

> Also, I'm against these extremely-managed/planned bureaucratic projects,
> with a feature freeze and various beta/RC phases that affect what you
> can and cannot do on master.
> 
> I think the process should be very simple:
> - You send out an email saying "it's release time again"
> - People nominate a git revision that's at least 1 week old so it has
>   been tested a little bit.
> - this revision becomes stable-RC
> - we decide if RC is good enough or whether small things need to be
>   fixed/cherry-picked
> - merge stable-RC into stable

Since the community is smaller, release/support cycles are shorter and we 
probably aren't going to guarantee much at first, yeah I think this is better.

I think, right now everyone in production does about the same thing:
1. pick a stable-looking recent git revision
2. test, fix
3. occasionally cherry-pick some needed fresh packages
4. cherry-pick critical fixes

If we can efficiently pool our efforts to do 1,4 and to some extent 2, why not. 
But lets not overstretch outselves with guarantees. It's always possible to 
extend your guarantees, it's much more painful to retract them.


More information about the nix-dev mailing list