[CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

Thu Apr 2 04:51:29 UTC 2015
Lamar Owen <lowen at pari.edu>

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.