[Nix-dev] Stable NixOS releases

[Marc Weber]

a) We should document what "stable" releases lack compared with trunk,
especially security fixes which are applied to trunk, but not to stable

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.

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

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.

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. Then if there are strong reasons
to upgrade to a newer version, guards could be introduced, so that you
have to opt-in for using the old version.

> - Archived installation CD images (e.g. unlike the current NixOS ISOs, they
> wouldn't be deleted after a while).
Well - its bad that you cannot configure your own sources anyway - that
nixos/nixpkgs from iso are used always.
However there was not enough feedback on the minimal install archive
code (which fixes this, too), to merge it with the minimal nix
setup distribution.

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?

Because nixos is so good at serving all users - I'd try to continue
doing so. Defining one use case will not work for everyone - so I would
not even try. Of course it can be done "officially" - but that could be
based on some arbitrarely chosen metrics based on something I talked
about.


> Adding new packages should be fine.  Adding new (major) versions of packages is
> also fine if they're marked as low-priority and don't change the default version
> of the package 
So like release.nix there could be a file determining which packages are
"watched" for release-hint updates - which should be the "default"
versions by default.

> default.  However, I don't anticipate that there would be many of these
> backports, but that depends on interest.
Community is still small - we should continue trying to optimize the
resources - and do backports if they make sense only.

> [...] hypothetical NixOS 13.06 I would nominate [..]
> (off the top of my head) KDE 4.10, GCC 4.8, and the current x-updates branch.
And gtk3, see my patches at nixpkgs

> I haven't thought very much yet about the actual release process (like "when to
> branch a release off the master").

Maybe - we actually don't have to. Eventually it could be done this way,
too:

config.release = "12"; // chose your personal set of default packages

config.release = "13"; // using same nixpkgs, change default set of packages ..

(Bady idea, hard to maintan .. :-)
But if you update "postgresql" only, such could make sense - and it
would be easy to document. The big question is: How often will upgrades
happen?

Eg an update log could look like this:

v13: adding postgresql 10 (now you can use both, opt in by choosing v13)
v14: adding new kde       (now you can give the new kde a try, opt in by choosing v14)
v15: adding new X
v16: kernel security fix (applies to all maintained versions v12,v13,v14,v15) 
                          - this would be a "backport!!" without being one)
v17: glibc security fix (applies to all maintained versions ...)

note: dropping postgresql 9 support (so use v13 or later)
note dropping  kde 4.7 support (so use v14 or later)
note dropping old X support (so use v15 or later)

So after this story you could be using v15 till v17 and older versions
should be supported in branches.

I'm not sure its a good idea - depends on the updates. It just shows
what could be done.

postgresql would be defined this way:

postgresql = if nixos-version > 13 then postgresql-10 else postgresql-9

Just some thoughts - we have to take care to not support too many
versions - things would be too difficult then - however in some cases it
might make sense.

Marc Weber