On Thu, 2015-04-02 at 00:51 -0400, Lamar Owen wrote: > Nor do I see it as an improvement. Thank you for your considered response. If it is not an improvement, then there is no reason for the change, is there ? > In my opinion, assigning sub-version numbers to what was originally > intended to be, by Red Hat, quarterly updates (almost Service Packs, > if you will, much like SGI's numbering of their Foundation and ProPack > products for the Altix server line) is what is illogical. Of course, > the updates aren't quarterly any more, and other aspects of the > versioning have morphed and changed over the years since the RHAS days > (well, even back in certain branches of RHL 6.2, for that matter). Whatever the original cause introducing sub-version numbering, that usage has become a clear progressive indicator of collections of updates within the major version. > in reality the update number is meaningless for compatibility checks, > as it is more than possible to have a fully updated CentOS x system > that claims to be x.0 but has all the packages, save centos-release, > of the latest x.y; further, it is easily possible to install the > CentOS x.6 centos-release package on a completely unpatched x.0 > system, making the contents of andy of the /etc/*-release files not > terribly useful for strict versioning. I image the vast majority of Centos users will not risk doing non-standard updates on their production systems so your above concern is unlikely to occur. > > Creating confusion where there was originally none is essentially silly. > > I am not so easily confused by the new numbering; I can not look at something labelled Centos 7.2169 and instantly know if it is Centos 7.1, 7.5 or even Centos 7.10. What's the latest version of Centos 6 ? Is it 6.32167 or 6.32782 or 6.32783 or should I be typing 6.23783 instead ? Confusion is not clarity. > > How many times has Johnny and others asserted that Centos is the same as > > RHEL ? > The assertion is that CentOS is functionally equivalent to the upstream > product. If Centos is "functionally equivalent" to RHEL then common sense must dictate that the sub-version numbers should be compatible too. -- Regards, Paul. England, EU. Je suis Charlie.