3 ms·
I'm not sure if you don't understand how RHEL/CentOS point releases and bugfixes work, or if you're reading something in the FAQ I'm not. Right now, in RHEL 8.
by kbenson 6y ago
I'm not sure if you don't understand how RHEL/CentOS point releases and bugfixes work, or if you're reading something in the FAQ I'm not.
Right now, in RHEL 8.2, if a package needs a bug fix, it will be back-ported so that you get the fix in the existing running version of that package that was shipped in 8.2. On point releases, RHEL (and thus CentOS) may choose to back-port a feature, functionality, or choose to update the version of the package that is running to a newer version that has those features or functionality (or to bring it in-line with back-patches, I assume). When you update to a new point release, this gives you a single large update set that you can test to make sure functions well in your infrastructure. There have been points in the past where changes in point releases have required us to make changes to our configs or setup to deal with the RHEL/CentOS's point release changes (even though it's supposed to be rare, it happens, but it's mostly contained to these big testable update sets).
CentOS mirrored this exactly, because it mirrored RHEL.
Now CentOS is going to do something different, and these updates that would be relegated to point releases look like they are going to come down continuously. While not as problematic as something like Fedora, this is still something that groups specifically chose CentOS to avoid.
It's nice that Red Hat is offering something to allow people to get fixes and features sooner than at point release times, but to switch CentOS to only providing that is extremely problematic to the very large community that expects otherwise, supported CentOS, and has done both since prior to Red Hat hiring some of the main CentOS developers and effectively controlling the project, and is notably different than what CentOS has always traditionally attempted to provide.