> Don't know why you would go with 9.0 on a new server
I understand what you're saying: normally, we wouldn't use a .0
release in production. But there's a problem. 8.2-RELEASE has
serious networking bugs that would cause the servers to lock up. It
also has a few other problems (e.g. in timekeeping) that we have
seen to cause instability. A small number of these are fixed in
8.2-STABLE (but to use it we'd not only have to build our own
unique snapshot but create a machine to build it on). Other
problems have been fixed in 9.0-STABLE but have not been
backported, perhaps due to the push to get 9.0 out the door. Some
will likely never be backported, either because they represent ABI
or architectural changes or because the developers' energies are
focused on not one but two newer branches.
And we need the servers now. See our dilemma?
IMHO, this problem stems from moving between major version numbers
too quickly rather than having at least 5 or 6 releases on each
major branch, leaving the last one or two highly polished so that
no one feels compelled to use a .0 release in production. While it
probably isn't a good idea to do more than 5 or 6 releases on a
branch, it does result in unparalleled stability. (Witness 4.11,
which may have been the highest quality release in FreeBSD's history.)
Using an official "RC2" build still wouldn't be ideal, because
freebsd-update couldn't be used to do a binary upgrade to the
release. (We'd still need to cvsup and "make world" on production
machines, which we do not like to do.) But at least we wouldn't
have to tweak configuration files, and would only have to rebuild
those application binaries that were statically linked. So far, it
seems like the best option, but I'd be interested in other suggestions.
--Brett Glass