[Nix-dev] Stable NixOS releases

Nicolas Pierron nicolas.b.pierron at gmail.com
Tue May 21 06:49:22 CEST 2013


Hi all,

On Tue, May 14, 2013 at 4:26 AM, Eelco Dolstra
<eelco.dolstra at logicblox.com> wrote:
> So what kinds of updates would be suitable for release branches?  Typically,
> conservative bug fix releases (e.g. Linux 3.4.45 -> 3.4.46, Firefox 20.0 ->
> 20.0.1), in particular security fixes.

I want to highlight one aspect which should be considered with such
release management.  As I know a bit about Firefox, I will take it as
example, but this also apply for all other packages.

Having a release cycle larger than the release cycle of the packages
is a security issue.  Firefox has a release cycle of 6 weeks, which
means that every 6 weeks users are "by default" updated to the latest
version of the browser.  If we omit the fact that Firefox maintains an
LTS branch (currently 17, soon 24), then we should better constantly
follow the latest release instead of keeping 20.0.1, because this
version will have no more security updates.

Then I don't think that we want to maintain our own version of Firefox
by back-porting security patches to an older version.  Doing so would
imply way more work, by people who are not necessary familiar with the
code.

- What can we do?

If we decide to have larger release cycle, we should either use the
LTS in the release branch, or use a beta/alpha version in the unstable
branch, such as the release never contain an unmaintained version.
Note that features available in beta/alpha version might not be
identical to the one of the release (last example in date, third party
cookies)


So, we should be careful when we claim that a release cycle is made
for taking only security updates, because the way packages are
maintained might not match our update policy.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/


More information about the nix-dev mailing list