Hi, A couple of days ago I had a brief discussion with Johannes regarding the 2.2 release, he suggested to post this as a proposal so we can abuse the new proposal process :) What I'd really like to see now that Per's gone for gold is a more defined release plan (also for future versions); I'm talking about formalizing a bit what happens when a new release is on the way. In our case that could be: 1. Someone builds devtest isos. These are for testing ISO ports only and get the core system into a consistent state. During this period: - The trunk only contains the ports that are on the ISO - the previous version port tree get all the updates and continues to work as usual. (I think the devtest phase is generally the longest one) 2. Once we're satisfied with the most recent devtest, we release a RC. The RC has a n-days lifespan (say 14). During these days: - maintainers will test and update their ports for the RC - only security fixes goes into the prev. release port tree - no changes are made to the core/opt ports included in the ISO to favour consistency. 3. If there are no reported problems the RC becomes the final release (otherways another RC is published). After the release: - port updates are generally applied only to the newly released port tree - we should keep a period in which we backport security fixes to the old port tree (we may as well have a dedicated volunteer / contributor) I'm not trying to be pedantic or to debianize CRUX, it's only that I think this would really help us optimize our limited workforce and help both developers and users make the switch to a new release. What do you think about it? -- Simone Rota Bergamo, Italy - http://www.varlock.com