On 2/2/21 10:26 PM, Nico Kadel-Garcia wrote:
Or.... a small miracle could occur, the mis-step of discarding point releases in favor of making all CentOS 8 users the beta users for RHEL, and CentOS go back to publishing point releases that match RHEL point releases. That was precisely what happened the last time Red Hat tried to discard point releases with "Red Hat 9" back in 2003. RHEL came out a few years later with point releases, and CentOS was developed to match.
The first 'pointless' release was Guinness (RHL 7), if I remember correctly. Nice bit of revisionism in your post, by the way, as the reality is that the CentOS 'point releases' came before RHEL's 'point releases.'
RHEL went with 'update rollup' numbering for a long while (up through 4U9), but the CentOS trees just replaced the U with a . instead; it's not been that long ago since that was finally retired at the end of ELS for RHEL 4U9 in 2017, although CentOS never had the ELS SRPMs to rebuild. So there was never a 'RHEL 3.1;' there was RHEL 3 Update 1 (3U1), up through RHEL 4U9. Yes, that is a bit of a semantic hair-splitting, but hear me out here....
It also wasn't a hard cutover where one day we had Red Hat Linux 9 and the next day we had Red Hat Enterprise Linux 3; RHEL (in the form of RHL 6.2E (which could be considered RHEL 1, even though it wasn't called that) and RHAS 2.1 "Pensacola") had been around for a bit prior to Shrike. Taroon (RHEL 3) came after Ca^H^HSevern, but Pensacola was released shortly after Ham^H^H^HSkipjack, in March 2002, a full year before Shrike (RHL 9) was released. A fun fact about Pensacola is, if I remember correctly, that it carried the MAJOR version of 2.1 through seven update cycles; so you had the last update roll-up package RHEL 2.1U7 in 2005, although it was supported through the end of May 2009; there was never a RHEL 2.2, and RHEL 2.1U7 is not RHEL 2.7. I still have a CentOS 2.1 VM running some internal code that had been running on RHL 5.2 up until three or four years ago (that RHL 5.2 box ran for almost twenty years). (Most of this information is available at https://access.redhat.com/articles/3078 although RHL 6.2E doesn't make that page; also see https://docs.fedoraproject.org/en-US/quick-docs/fedora-and-red-hat-enterpris... )
So Red Hat taking a year to get its toes wet and figure out what to do isn't a new thing; RHEL releases overlapped 'regular' RHL releases for three years if you count Red Hat Linux Enterprise Edition 6.2E as 'RHEL 1,' which was GA on 2000-03-27; Shrike (RHL 9) went GA on 2003-03-31, although Cam^H^H^HSevern (the supposed RHL 10 beta) went public beta 2003-07-21; Taroon (RHEL 3) didn't go GA until 2003-10-22. It took Red Hat that long to make the tough decision to get out of the 6-month-cycle retail boxed set space.
Back to the versioning, originally the 'RHEL Y Update X' releases were considered (at least by me) as 'update rollups' (Windows-speak: Service Packs or just see MS' definitions at https://docs.microsoft.com/en-us/troubleshoot/windows-client/deployment/stan... ) and not 'point releases;' it wasn't until RHEL 5 that they really can be considered 'point releases' if I remember correctly. And I always reserve the right to be wrong, or to mis-remember things, but I'm using my private archives of several mailing lists, public and private, for source material here, as well as the two histories I've linked to above. Updating was pretty primitive back then, and it had not been long since the first version of 'up2date' had been released. Having 'update rollups' released on CD is convenient, especially for new installs, rather than install the GA and slog through all the updates to get up to the current update set.
But with 5.x through 8.x Red Hat seems to have yielded to the 'point release' model, and the pattern changed somewhat relative to what had been the case with RHEL 4Ux, with much more major changes happening in early 'minor versions' (which is what I take 'point release' to mean, instead of just being my perception of the original 'update rollup' model where there aren't really 'minor versions' in this sense). So your 'few years' is technically correct for RHEL.
HOWEVER, the CentOS releases always had the confusing 'point' in them (see vault.centos.org's directory tree). BUT, the Red Hat FTP site with the source RPMs have neither point releases nor Update numbers visible anywhere; you have the GA SRPMS and the updates SRPMS (all of them, not just the latest version, stuffed into a single directory). There is NO tag to show, in the updates tree, which update (or point release) had what SRPM. You can look for yourself; that FTP site is still up and still has the historical SRPMs in it; the base directories are http://ftp.redhat.com/pub/redhat/linux/updates/enterprise/ and http://ftp.redhat.com/pub/redhat/linux/enterprise/%C2%A0 (for regular RHL everything is at http://archive.download.redhat.com/pub/redhat/linux/ ). CentOS 2.1 is a special case in this regard; CentOS 3.1 should really be considered the starting point; there is no CentOS 3.0.
So CentOS Stream, other than only containing the latest RPMS, follows right in the footsteps of RHEL's SRPMS distribution pattern that's been from the very beginning; if all you have are the RHEL SRPMS there are NO point releases to be seen anywhere. This 'pointless-ness' is NOT really a change in direction for RHEL; it is a change in CentOS users' (and later RHEL users, VARs, and software/hardware vendors) assumptions about 'point releases' that were addressed (at least an attempt was made to address the assumptions) by the CentOS 7 'pointless' versioning that everybody got riled up about.
It is understandable that people want a reference point for support; a rolling release model makes that difficult, and thus 'point releases' to provide such a reference point becomes SOP, even if that 'point release' is horribly out of date and insecure, but has the shared-library link-print that the software or hardware needs.
I welcome informed corrections and additions to what I've written here; I was an observer during this time for the most part, not a 'doer' of any rebuild itself, and my perspective is biased a bit by that point of view, I'm sure.