On Tue, May 14, 2013 at 05:44:43PM +0200, Mathijs Kwik wrote: > On Tue, May 14, 2013 at 5:33 PM, Eelco Dolstra > <[email protected]> wrote: > > On 14/05/13 14:25, Mathijs Kwik wrote: > > But the risk with this approach is that people will be tempted to squeeze in > > wildly destabilizing changes at the last moment :-) I don't think this > > needs a > > lot of bureaucracy or rules though, just some good sense not to (say) merge > > a > > major GCC update into master just before the release is about to be > > branched. > > I think stdenv-updates is still the only right place for those. > Same for x-updates. We should not declare master > "anything-can-break-now" just because we have stable, so maintaining > master somewhat the same as we do now (with feature branches for > larger undertakings) seems best.
The NixOS success is a bit bound to the way it is developed. I wouldn't consider that the current practices should be changed. I'd start with those release branches without affecting how things are committed to master / stdenv-updates. Isn't this easier? (I didn't read the long previous comments) Regards, Lluís. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
