On May 11, 2016, at 9:38 AM, m.roth@xxxxxxxxx wrote:
>
> Warren Young wrote:
>> This isn’t just about RHEL vs Debian and
>> derivatives of same. Several major non-Linux OSes also manage to do
>> automatic upgrades between major releases: Windows, OS X, FreeBSD...
>
> I was under the impression that all the releases of OS X were more like
> what we call subreleases (6.6->6.7).
You can’t transfer meaning between different version number systems. There is no global standard for the meaning of version numbers. The only thing that matters is that there is internal consistency.
(Which is why Windows version numbering is a joke.)
OS X treats changes to the ‘x’ component of their OS X 10.x.y version numbering system about the same way as EL does in its x.y system. The only difference is that major OS X versions have been coming out yearly in recent years, so that there is less cumulative difference between major versions than in CentOS major versions. But there’s probably at least as much change every 3 major OS X versions, as you’d expect since CentOS major versions are also about 3 years apart.
And, in fact, OS X will allow itself to be upgraded across major OS versions. It doesn’t demand that you upgrade to each intermediate version separately.
Calling OS X major releases “subversions” is just as fallacious as the opposite problem we see here in the CentOS world, where some people believe that CentOS 7.1 is incompatible with CentOS 7.2. A change to y in these two x.y system means something very different, yet both are correct because both systems are internally consistent.
>> Your point about the 10 year support cycle for RHEL is also invalid. The
>> time spacing between major releases is only about every 3 years, and that
>> is the period that matters here.
>
> No, it's not invalid, nor is it what matters. For example, here at work,
> we have clusters, and a small supercomputer, all running 6.x (in the case
> of the supercomputer, it's an SGI-modified RHEL 6.x), and they'll go to 7
> probably when they're surplused replaced.
Yes, and…? Just because you have one use case where a major version upgrade does not make sense does not mean that major version upgrades don’t make sense everywhere.
I already covered that case in my previous post, and the counterargument remains the same: not all OS upgrades can be coupled with hardware upgrades. VMs are only one reason, though a big one.
As for all the rest of your post, yes, I get it: nothing should ever change, nothing should ever break. You just go and live live that dream. Meanwhile, in my world, change happens. Your unwillingness to cope with it does not prevent me from doing so.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
