On 2 Apr 2015, at 06:41, Always Learning centos@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