Hi all, On Tue, May 14, 2013 at 4:26 AM, Eelco Dolstra <[email protected]> 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/ _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
