On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik <j...@kozubik.com> wrote:
And as long as we're repeating ... :)
Since 9.0 is already out of the bag, I think a decent approach would be
to fizzle out 8.x on the current timeline/trajectory (maybe 8.4 in 6-8
months, and maybe 8.5 in a year or so), then:
- EOL 7
- mark 8 as legacy
- mark 9 as the _only_ production release
- release 10.0 in January 2017
And in the meantime, begin the every 4-6 month minor releases that we
all agree can occur with 9. By Jan 2017, you get to 9.12 or 9.14 or so.
This is nice because no upheaval needs to happen with 7 and 8, and
interested developers do not get kneecapped vis a vis 9 - they can just
keep going where they were going with it, and the only real change is
that 10 is pushed out a long ways, and people[1] get to really sink
their teeth into 9.
What are the policies for changes though? Are we stuck with 9.0's feature
set for 5 years? Will we have to wait 5 years to get a stable release of
FreeBSD with KMS/GEM? That work is unfinished and didn't make 9.0; it's
also a huge changeset. How will things like this be dealt with? Five years
is a long time for the next stable release if we have a policy to not
import major changes from -CURRENT. It would be devastating to so many
users.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
