Johnny,
>> Red Hat has a tree ... we can pick any one, I'll use 6.4 as an example.
>> When Red Hat releases 6.4 they release an ISO set and a tree. Red Hat
>> splits their tree up into several versions, for which they can charge
>> varying amounts of money (Server, Workstation, HPC Node, Client, etc).
What about this as a reasonable compromise on the proposed version numbering?
<major>.<minor>.<date-code>
with the <date-code> in ISO8601 format (four-digit year, two-digit month, two-digit day).
This would translate as CentOS <major> version built from RHEL "baseline" <major>.<minor>, plus all publicly available updates as of <date-code>. ("baseline" = RHEL ISO set, for example: RHEL 6.4)
By using ISO-8601 format for the <date-code> ensures the least confusion when parsing it as a date field and it also sorts properly / compares properly when looking at previous dates.
Applying the above as the pattern, a RHEL 7.0 baseline + CentOS 7 updates as of 2014-06-20 would result in this as a version string:
7.0.20140620
Easy to parse for both the humans and the computers; relatively easy to understand for both old and new folk.
Humans might understand better that updates for a particular branch (for example: 6.4) end after a given date. And management might understand better, why move from 6.4 to 6.5; because no patches/updates for 6.4 after YYYY-MM-DD.
Asking the humans, What is the patch date of your system? = read me the eight-digit number on the right-hand side of the version string. Is that number earlier (sometimes much earlier) than the current date? Yes = use 'yum update' to bring the system up to date; no, proceed to next step in troubleshooting issue, with a reasonable assurance that they are on a current release.
This helps focus on the two important parts, the <major> version and the <date-code>, while still keeping the <minor> field available for those who are comparing their CentOS install with relatively comparable system that was installed from a RHEL ISO media set.
Nothing would have to change regarding the current policy of CentOS not providing updates for a previous <minor> baseline once it moved forward to a new <minor> baseline. Installing from an older ISO image within the same <major> version of CentOS and then calling 'yum update' should still result in the system being brought up to date with the latest <minor>.<date-code> set of patches/updates.
For the various SIGs; if they had separate spins of the media, they could use a suffix attached to the core version string; for example: CentOS 7.0.20140620-cloud.<cloud-version>.
Thank you and your team for providing us with CentOS over the years.
Cheers!
Simba
Engineering
(long-time UNIX, Linux, and many other UNIX-based OSes since UNIX v7 :-)