[CentOS-devel] Before You Get Mad About The CentOS Stream Change, Think About…

On Wed, Dec 23, 2020 at 2:14 AM Gordon Messmer <gordon.messmer at gmail.com> wrote:
>
> On 12/22/20 10:36 PM, Nico Kadel-Garcia wrote:
> > It's why I say they're taags" and find the model
> > mentioned here that "it's all one branch" to not match reality
>
>
> For fun, I'll try again:
>
> RHEL point releases are branches.  7.6 is a branch.  7.7 is a branch.
> You can continue running 7.6 and receive security updates after 7.7 is
> released.  Those updates may include packages built specifically for
> 7.6, and not just a selection of the packages for 7.7.  They're
> maintained in parallel, at the same time.  They're branches.

It's a point release, with a defined and immutable content. In
subversion, git, CVS, and other source control terms, it's a tag that
someone doesn't want to call a tag.

> CentOS point releases weren't individual branches.  There was only one
> CentOS 7 branch.  CentOS 7.6 was just a point in time along the lifetime
> of CentOS 7.  7.6 is not literally a tag, but it's the closest analogy.
> There was no continued support for CentOS 7.6 after CentOS 7.7 was
> released.  If there's no parallel maintenance, there is only one branch.

Seriously, no one cares. Both RHEL support, and CentOS support for
updates pointed users to the current software channels for the leading
repos and sayd to "yum update" whatever the particular package was. If
you did "yum update", with either, yes indeed you got the leading edge
of *everything* and lost the stability of haveing a well defined point
release.  None of that means that the point releases were not
essentially "tags", well-defined states of the repository useful as a
stable reference for build environments, business class environments,
or clusters.

As a stable set, it was effectively a tag, no matter what the upstream
source management was.

> RHEL point releases get updates that aren't just updates for a later
> release.  As an analogy, there are updates in the older branches that
> aren't in the new branches, unlike CentOS.

As I understood from dealing with Red Hat, they're short term, for
specific customers, and discarded as quickly as possible. Everything
gets migrated to the main codeline or discarded. If it never got
brought into the main CentOS codeline, frankly, I couldn't use it, I
had too many mixed system to burn cycles resolving that kind of
discrepancy.

> CentOS has just one branch:
>
> * 7.5
>   \
>    * 7.6
>     \
>      * 7.7
>
> RHEL has multiple branches that overlap in time:
>
> * ---- 7.5
>   \
>    * ---- 7.6
>     \
>      * ---- 7.7

As long as tweaks get folded back into the main release contents, and
Red Hat was very good about that, no one cared. Stopping the support
of the point releases was the whole point of Red Hat 9, and RHEL
continues the practice on their support lines. The last time I called
them about this (perhaps 3 years ago?), the main response to "I need
to fix this particular release's issues" was to try to sell me on
host-specific RPM inventory tuning with a very expensive and unwelcome
RHN setup that would have been very expensive and unsustainable
because my contract was short term. The "rsync for CentOS" or
"reposync for RHEL" internal yum repos were *much* more effective, and
also made it possible to scale up hundreds of hosts for a cluster
simultaneously without choking our external bandwidth to death.