[Nix-dev] Stable NixOS releases

[Mathijs Kwik]

On Tue, May 14, 2013 at 5:33 PM, Eelco Dolstra
<eelco.dolstra at logicblox.com> wrote:
> Hi,
>
> On 14/05/13 14:25, Mathijs Kwik wrote:
>
>> I would prefer a 3 months cycle.
>> 6 months is quite long, making upgrades (possibly) harder to do.
>
> Agree.  OTOH, there is the question of how long release branches are maintained.
>  For now I'd say that a release branch should be maintained until the next
> release comes out.  In the future we could have releases that are maintained for
> longer (such as a LTS branch).
>
>> 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.
>>
>> 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
>>
>> Preferably the whole process takes at most 4 or 5 days.
>> Announcement on wednesday, release on monday. This makes the weekend
>> into a nice community-hackathon :)
>
> But the risk with this approach is that people will be tempted to squeeze in
> wildly destabilizing changes at the last moment :-)  I don't think this needs a
> lot of bureaucracy or rules though, just some good sense not to (say) merge a
> major GCC update into master just before the release is about to be branched.

I think stdenv-updates is still the only right place for those.
Same for x-updates. We should not declare master
"anything-can-break-now" just because we have stable, so maintaining
master somewhat the same as we do now (with feature branches for
larger undertakings) seems best.

>
> Also, having release goals (as in "these are the features we'd like to have in
> this release") seems like a good way to focus development (and to get people to
> volunteer to work on those features).
>
> --
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev