3 ms·

From the FAQ https://centos.org/distro-faq/ https://centos.org/distro-faq/ : "Q6: Will there be separate/parallel/simultaneous streams for 8, 9, 10, etc? "A:

by teilo 6y ago

From the FAQ https://centos.org/distro-faq/ https://centos.org/distro-faq/ : "Q6: Will there be separate/parallel/simultaneous streams for 8, 9, 10, etc? "A: Each major release will have a branch, similar to how CentOS Linux is currently structured; however, CentOS Stream is designed to focus on RHEL development, so only the latest Stream will have the marketing focus of the CentOS Project. "Because RHEL development cycles overlap, there will be times when there are multiple code branches in development at the same time.This allows users time to plan migrations and development work without being surprised by sudden changes. "Specifically, since the RHEL release cadence is every 3 years, and the full support window is 5 years, this gives an overlap of approximately 2 years between one stream and the next." Also from Q2: "We will not be producing a CentOS Linux 9, as a rebuild of RHEL 9. Instead CentOS Stream 9 fulfills this role. (See Q6 below regarding the overlap between concurrent streams.)" So it sounds to me like my assumption is correct: There will be separate streams reflecting each RHEL release. Read the whole FAQ. This is not what people think it is.

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.

by teilo 6y ago

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.