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

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.

you guys sure get your panties in a bunch over something as silly as the 
iso file name.

if you don't like the name, rename it... sheesh.



-- 
john r pierce, recycling bits in santa cruz

On Wed, Apr 1, 2015 at 10:12 PM, Les Mikesell <lesmikesell at gmail.com>
wrote:
> Adding the date component means CentOS may release more than one iso
> per RH's minor versions.  There isn't much of a consistent
> relationship between the RH release and the subsequent Centos release
> other than 'sometime later when it is ready'.   So, given a set of
> Centos isos or even just the most recent, how would you know which RH
> release it is based on?  Download, install, and read the
> /etc/os-release file before finding out?   Or look up some other
> source of the missing information?
This could be that "some other source":

http://wiki.centos.org/Download
(go to the "Archived Versions" section)

Akemi

> On 2 Apr 2015, at 06:41, Always Learning <centos at u64.u22.net>
wrote:
> 
> 
>> On Thu, 2015-04-02 at 00:51 -0400, Lamar Owen wrote:
>> 
>> 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.  
The new version numbering is too.
>>> 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.
Because CentOS 7.1 7.2 etc do not exist. 7.1503 etc does. These are also dates
so 6.23783 would never exist. Though assuming a valid date, the bigger number
would be the latest (year first then month so it is sortable.)

I don't recall the thread or even where but I do remember a discussion that
7.1.1503 is not really semantic I think and potentially in itself confusing as
you end up incrementing two numbers. The sub version becomes irrelevant as all
the detail (point in time) lies with the date. The sub version becomes purely a
remnant from RHEL with no specific purpose except to be a reminder.
>>> 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.
I disagree. It's purely irrelevant in most cases.

Though one thing I do agree on is how to tell (roughly) which sources the CentOS
release is based on. In which case the sub version number would be useful for
academic reasons. For instance the release notes don't even mention RHEL 7.1
at all when I looked. Though you can usually match up the dates with the RHEL
timeline so you can see when you're about to receive hundreds of updates.

So I can appreciate the concern somewhat on that regards. Maybe somewhere else
needs to state it such as release notes and announcements (if those don't
already.)

Jason

On Thu, 2015-04-02 at 07:09 -0400, mark wrote:
> Had you, for example, made it release.subrelease.date (7.1.1503), it would 
> have been less disruptive and annoying.
An excellent suggestion that everyone can live-with.  Bravo.


-- 
Regards,

Paul.
England, EU.      Je suis Charlie.