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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
