On Wed, Dec 23, 2020 at 2:14 AM Gordon Messmer gordon.messmer@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.