[CentOS-devel] First round of RHEL programs announced

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-enterprise-linux/index.html 
)

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/standard-terminology-software-updates 
) 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/  (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.