[Nix-dev] Stable NixOS releases

[Eelco Dolstra]

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.

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/