On Tue, May 14, 2013 at 5:33 PM, Eelco Dolstra <eelco.dols...@logicblox.com> wrote: > Hi, > > On 14/05/13 14:25, Mathijs Kwik wrote: > >> I would prefer a 3 months cycle. >> 6 months is quite long, making upgrades (possibly) harder to do. > > Agree. OTOH, there is the question of how long release branches are > maintained. > For now I'd say that a release branch should be maintained until the next > release comes out. In the future we could have releases that are maintained > for > longer (such as a LTS branch). > >> Also, we probably want releases to be backward compatible 1 release >> (regarding configuration.nix and nix features), so a long cycle might >> complicate things or hold back master development. >> >> Also, I'm against these extremely-managed/planned bureaucratic projects, >> with a feature freeze and various beta/RC phases that affect what you >> can and cannot do on master. >> >> I think the process should be very simple: >> - You send out an email saying "it's release time again" >> - People nominate a git revision that's at least 1 week old so it has >> been tested a little bit. >> - this revision becomes stable-RC >> - we decide if RC is good enough or whether small things need to be >> fixed/cherry-picked >> - merge stable-RC into stable >> >> Preferably the whole process takes at most 4 or 5 days. >> Announcement on wednesday, release on monday. This makes the weekend >> into a nice community-hackathon :) > > 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. > > Also, having release goals (as in "these are the features we'd like to have in > this release") seems like a good way to focus development (and to get people > to > volunteer to work on those features). > > -- > Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev