Date: Wed, 18 Jan 2012 19:56:57 -0500 From: "Dieter BSD" <dieterbsd@engineer.com> To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <20120119005658.218280@gmx.com>
next in thread | raw e-mail | index | archive | help
John writes: > - EOL 7 > - mark 8 as legacy > - mark 9 as the _only_ production release > - release 10.0 in January 2017 Until a few days ago 8 was the latest, shinest release. So you want to suddenly demote it all the way down to legacy? I thought the goal was to have releases that can be used for a long time? On the one hand, many users want/need releases to have a long lifetime. On the other hand, we want to be able to start a new release when some new major feature is mature enough. If these features come out often enough, we end up with a lot of releases to support, and supporting a lot of releases uses up a lot of time and effort. Assuming that a lot more resources aren't going to magically appear, perhaps the solution is to ramp down the level of support for older releases. 7 - legacy (only gets fixes for security, panic/hang, data loss) 8 - supported (security, panic/hang, data loss bugs, plus others as requested) 9 - very supported (most improvements that aren't massively disruptive) stable - not quite bleeding edge, not a "release" yet, not recommended for production, brave users can try out new features current - bleeding edge The legacy level shouldn't have many fixes, so it shouldn't take too much time and effort. It should be possible to support multiple "legacy" releases. If fixes only get backported to "supported" releases when users request it, the amount of time and effort may be low enough? I don't have a good idea of how many requests would be made. If the requests are infrequent enough, it might be possible to support more than one "supported" release. (Better names for "supported" and "very supported" would be welcome.) A time based schedule can make sense if there are a lot of small changes. It doesn't work as well with fewer large changes. If the clock says it is time for a new major release but none of the major new features are ready, it doesn't make sense to do a major release. A time based schedule might make more sense for minor and point releases?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120119005658.218280>