On Wed, Jan 18, 2012 at 12:27 PM, Doug Barton <[email protected]> wrote: > On 01/18/2012 11:46, John Kozubik wrote: >> - mark 9 as the _only_ production release > > What I've proposed instead is a new major release every 2 1/2 years, > where the new release coincides with the EOL of the oldest production > release. That way we have a 5-year cycle of support for each major > branch, and no more than 2 production branches extant at one time. > > History tells us that 2 production branches is a goal we can achieve, > with the focus shifting more heavily towards only bug/security fixes in > the oldest branch after the new production release branch is cut. If we > combine that with the ideas that are being put forward about teams that > "own" a production branch, and a more frequent stripped-down release > process, I think this is a very workable model.
This is similar to how Debian works (the other OS we use the most often). They have "testing" (aka -CURRENT) where all the new development takes place, that will eventually become the next major release; "stable" (aka production -RELEASE) which sees minor (actually, point) releases every few months; and "oldstable" (aka legacy -RELEASE) which sees no development beyond major security/bug fixes. There's approximately 2 years between major releases, at which time "oldstable" is EOL'd, "stable" becomes "oldstable", "testing" becomes "stable", and development continue with the new "testing". I can see something like that working for FreeBSD, as you've outlined it above. It seems to work well for them, although it's not a perfect comparison since the Debian devs don't do a lot of development on their own, it's more integration and testing work with software from a bunch of other, independent projects. What would be really nice, though, to help with the above, is a branched ports tree that followed the same release schedule. Perhaps it's time to dust off my coding skills and jump back into port maintenance. -- Freddie Cash [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
