On 04/02/15 00:51, Lamar Owen wrote:
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.
But only those on the devel list ever saw the discussion. Those of us whose
job it is to be sysadmins, and run many systems, don't tend to be on that list
also.
Had you, for example, made it release.subrelease.date (7.1.1503), it would
have been less disruptive and annoying.
mark
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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
