Re: There is currently no usable release of FreeBSD.

On 6/5/14, 12:52 AM, John Kozubik wrote:
>
> freebsd.org website shows the following:
>
> Production: 10.0
> Legacy: 9.2, 8.4
> Upcoming: 9.3

right now the best release to use in production is probably 9.2.
if you are like me you would have the following:

production on 9.1 or 9.2 having upgraded from 8.3 or similar about a 
year ago
some early test systems on 10-stable getting ready for 10.1
one system on -head "just because.."

>
> You can't put an x.0 release into production (a bigotry that is 
> *well deserved* in light of 5.0 and 9.0) ... and 9.2 and 8.4 are 
> legacy ... and we all know that 9.3 is as far as the 9 branch is 
> going to go, so that's a dead end for any serious deployment.
I believe you put too much emphasis on moving up a branch.
  .. Though I will admit the gcc -> clang change between 9.x and 10 is 
a bit of a worry commercially, which is why *WE* will
move from [what we run now] to 10.0++ but with clang disabled and 
still using gcc, with a planned "minor" upgrade to 10.0++ compiled 
with clang about 6-9 months later.

My experience upgrading customers like Bank Of America (at a previous 
job) showed that FreeBSD's inter-branch upgrades were usually a whole 
lot less trauma than upgrading a release of Windows.
I also believe that FreeBSD's .0 branches are not as bad as you make 
out. I've used them many times.

>
> Let's pretend for a moment that you are going to use FreeBSD for 
> something other than FreeBSD development.  Let's pretend that you 
> have customers and shareholders and boardmembers and contracts and 
> regulators.
>
> Which version of FreeBSD would you use ?
as explained above..  if we were doing an upgrade now, we'd be 
planning for 10.1 in a few months time, but if we'd done it 6 months 
ago we'd have gone to 9.2 and be planning an upgrade to 10.1 in 
another 6-12 months. In the jobs I've had we rarely  actually used the 
"RELEASE" exactly, but our own build of it. there is nearly always 
something you want to change.
So we tended to build from a snapshot of one of the branches, taken at 
release time.. so you can roll forwards with source control to reroll 
your build , but with the security fixes..

Usually we have one or two (or more) of our own changes to apply in 
the build process.
(bug fixes or our own driver .. whatever).
on SVN or Perforce we have our own branch which mirrors the FreeBSD 
one (but has our own additions)
in CVS we used to just keep extra patch files we'd apply after checkout.

It really depends on what you are DOING with the systems you deploy.

> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to 
> "freebsd-hackers-unsubscribe@freebsd.org"
>

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"