[Nix-dev] Stable NixOS releases

[Eelco Dolstra]

Hi,

On 14/05/13 15:51, Marc Weber wrote:

> b) keeping a roadmap (what changed in topic branches or trunk) is a
> great idea - so people know more easily which version to run - and
> release messages are easy to write
> 
> How to do it? I'd prefer not use github pages - while it would work
> I'd like to introduce branch specific info files - such as
> 
> ./BRANCH_INFO.txt
> 
> to which a summary of the important changes could be written.

You're talking about release notes here, which are a separate thing from the
issue tracking in Github (though you can use the issues to write release notes).
 I'd suggest putting the release notes in the NixOS manual or maybe on a wiki page.

>> --upgrade" and find that the Linux kernel or PostgreSQL or PHP suddenly changed
>> to a different major version.
> What are you talking about?

As Evgeny said, the point is to ensure that a "nixos-rebuild --upgrade" does not
break your system, with some reasonable level of confidence.  I.e. there should
be no regressions.

> PHP 5.2 is no longer maintained, you should no longer be using it in
> production. Since the incompatible 5.2 to 5.3 upgrade PHP devs said
> there will be no such big breaking update again.

I'm not enough of a PHP user to comment on their backward compatibility, but I'm
somewhat skeptical that it's safe to upgrade to a new major PHP release on a
production server without testing.  But certainly the default PostgreSQL version
should never ever change in a stable branch, because 1) you need to do a
dump/restore of the database; 2) PostgreSQL is rarely 100% backwards compatible.

> About postgresql, PHP: Does it really make sense to force major releases
> whenever any package changes ? I mean there are undreds of packages
> which could break - which should cause a major release is not always
> easy to understand - eg adding a new ghc compiler could also be a reason
> to create a major release - so release cycles will always be subject to
> individual taste to some extend.

With a periodic release schedule, you don't create a new release because there
is a new GHC.  Rather, a new GHC can be a feature of a new release.

> But even then - you may want to update to latest release, but keep old
> postgresql - how to do it? I guess the only way would be starting to
> maintain multiple postgresql versions - and configure in
> configuration.nix which one to use.

This is exactly the case already :-)  We have 5 different PostgreSQL versions in
Nixpkgs (of which 4 are maintained upstream).

> How could we automate to determine whether a new release is worth
> creating? Does it make sense to create new meta attributes?
> 
> meta = {
>   release-hint = 2; // bump if you think this should trigger a new nixos
>                     // release, and add a short comment why?
>   release-hint-message = "postgresql changed in an incompatible way, see http:// ...";
> }
> 
> This would allow to define your own metrics for your custom installation
> to determine whether updating might cause trouble - I mean if you don'
> use postgresql, you don't care about such an update, right?

This won't work because it fails to take into account all the ways in which
seemingly irrelevant changes to dependencies or other system services can break
your system.  Also, it only warns you - it doesn't provide you with a safe
upgrade path.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/