[Nix-dev] Stable NixOS releases

[Vladimír Čunát]

A very good point.

On 05/21/2013 06:49 AM, Nicolas Pierron wrote:
> 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.

We certainly don't want to :-)

> - 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.

It seems we should use ESR versions (that's how they call them) but they 
only have 12 weeks of overlap between maintaining the old ESR and 
releasing another ESR. We could synchronize our cycles with theirs (they 
have ~12 months ESRs) to have switches in those overlapping intervals, 
but it's likely there are more such packages with incompatible cycles 
and we have a problem...

[Firefox ESRs]: http://www.mozilla.org/en-US/firefox/organizations/faq/

I suppose here we could look how other longterm distros do this, to get 
some inspiration. The rules should be vague/flexible anyway, so we can 
catch these cases... e.g. not too many packages depend on firefox/libXUL 
so one change somewhere during the stable release shouldn't hurt too 
much. I believe the major change restriction was mainly because of 
servers on NixOS, where short-cycled apps like firefox aren't so 
important ;-)


Vlada


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3251 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20130521/1e962133/attachment-0001.bin