On 04/01/2015 08:12 PM, Always Learning wrote:
1. What is the logically reason for this alleged "improvement" ?
I never said it was an improvement. I just said that I didn't think it
was that big of a deal, and it boggles my mind that people are calling a
change of an ISO's file name 'unwise' and even comparing it to a
Microsoft move. I just don't see it as being that big of a problem.
Nor do I see it as an improvement. But the question was asked about
where such a change might have been discussed, and I pointed to the long
and drawn out centos-devel thread in which the background for the
date-based numbering was beaten to death (and beyond). The CentOS devs
have stated that the CentOS Board voted on it, and they have the
decision-making power to do so. And they are all reasonable people.
2. How are users of all types, from all around the world, benefiting
from this change ?
This change makes it unequivocally clear that CentOS 7.1503 is not
exactly the same as upstream RHEL 7.1, although it is functionally
equivalent (where the meaning of functionally equivalent has been hashed
to death, too, but it basically means binary-compatible but not
necessarily binary-identical). Whether you consider that a benefit or
not is up to you. I'm personally neutral on the issue.
Consolidating two replies:
On 04/01/2015 07:58 PM, Always Learning wrote:
On Wed, 2015-04-01 at 16:15 -0400, Lamar Owen wrote:
On 04/01/2015 03:33 PM, Always Learning wrote:
(1) removing sub-version numbers is wrong; and ...
That is a matter of opinion. 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).
So you could read '7.1' as 'version 7 service pack 1.' My opinion is
that sub-version numbers give a mistaken impression that the update
number is a real 'version' when it was not originally so. Further, 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.
It is my opinion, although it's not a vehement opinion, that beginning
the x.y practice is what was illogical. But it was done, and it is
over, and I have more important things to do than gripe over semantics
such as that.
Creating confusion where there was originally none is essentially silly.
I am not so easily confused by the new numbering; what the ISO is named
is orthogonal to what it contains, at least in my mind.
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. It is not 'the same as' nor can it be and still remove the
trademarked branding of the upstream release. It is binary compatible
without being binary identical. And as the meaning of 'binary
compatible' has also been hashed to death, I'll not further clutter the
traffic on this list about what it means. It's easy enough to read the
centos-devel archives to see for yourself.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
