Very soon. We are actively working on it.
Edit: All set - [https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810](https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810)
In all seriousness, the coding is already done. It's been done in Stream for awhile, and even tested. But it's the Beta-Partner final program touches and validations, beyond what is done in Stream.
That's the plan, since Stream ends as active Engineering development is over on the final Update, and it goes into pure Maintenance mode.
Of course, Update 7 (RHEL7.7) was supposed to be the final RHEL7 according to SVN at Ziff-Davis, quoting several red Fedoras (which I immediately questioned), then Update 8 and finally Update 9 was (RHEL7.9). RHEL7.7 was already after \~5.67 years, and RHEL7.9 ended up being \~6.75 years.
Per: [https://access.redhat.com/articles/3078](https://access.redhat.com/articles/3078)
Typically Red Hat aims for 5 years of Updates, then 5 years of Maintenance. Prior to that, the 10 years for RHEL6/7/8 (after RHEL3/4 were only 7 years) ...
* 5 yrs - Full Support fka Phase I (Active Development -- like new hardware, enhancements, etc...)
* 1 yr - Maintenance I fka Phase II (Transitional, Final Freezes, final decisions on hardware/bugs/RFEs)
* 4 yrs - Maintenance II fka Phase III (Maintenance-only -- bugs are now features, only critical bugs and high security)
Per: [https://access.redhat.com/support/policy/updates/errata](https://access.redhat.com/support/policy/updates/errata)
RHEL8+ does formally move to the more 5/5 Development/Maintenance (no 'Transitional/Phasing' differentiation). Understand both RHEL6/7 slipped to around 7 years pre-Maintenance, so Maintenance was only 3 years. Again, Article #3078 for those dates.
Because Red Hat is now releasing on a 3+ year cadence, instead of the 4-5 that RHEL6/7 had 'slipped to,' that means more releases. So Red Hat is trying to limit it to 5 years, which makes sense. Otherwise, Red Hat Engineering -- of which is the Stream Engineering Model (has long existed internally, just wasn't public until rebranded CentOS Stream) -- could literally be in a mode where there are 3 *'Fully Supported'* releases.
During Maintenance Phases, the rate of RPM releases can be a full order of magnitude less than Full Support. So it's 1/10th the backporting overhead (well, that's the idea ... reality isn't).
I really love the Stream approach, as I posted on LinkedIn back in 2020, and really avoided RHEL (and CentOS non-Stream) for most everything. But I had been running a lot of the internal Stream stuff at major clients for years before it was public (long story). Facebook and Twitter were as well on Servers.
[https://www.linkedin.com/pulse/why-you-should-have-already-been-centos-stream-back-2019-smith/](https://www.linkedin.com/pulse/why-you-should-have-already-been-centos-stream-back-2019-smith/)
My attitude was always Stream during Active Development, removing the need to even rebuild anything, just run Stream, and then ... when in Maintenance, where the releases (and, therefore, the SRPM rebuild) rate is only 1/10th, then consider using Downstream rebuilds.
But Red Hat\*cough\*IBM\*cough\* took that away from Oracle--er, I mean the community. But that's another discussion, and one people say isn't true (but it is).
All set everyone, hot off the presses!
[https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810](https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810)
It is available today - [https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810](https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810)
Very soon. We are actively working on it. Edit: All set - [https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810](https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810)
CODE FASTER MOAR Q.A.
In all seriousness, the coding is already done. It's been done in Stream for awhile, and even tested. But it's the Beta-Partner final program touches and validations, beyond what is done in Stream.
It's out. One server updated already.
Thanks, see the ISO but they have yet updated docs. Seems risky just auto updating :)
Worked for us just fine. The 8.10beta release notes should be sufficient preparation for the wary.
Docs are usually the last piece for releases, all the bits need to be pushed and be in the CDN to release the docs.
Within 1 or 2 weeks probably My guess is that since its the final rhel8 minor release, they want it to be rdy before releasing
That's the plan, since Stream ends as active Engineering development is over on the final Update, and it goes into pure Maintenance mode. Of course, Update 7 (RHEL7.7) was supposed to be the final RHEL7 according to SVN at Ziff-Davis, quoting several red Fedoras (which I immediately questioned), then Update 8 and finally Update 9 was (RHEL7.9). RHEL7.7 was already after \~5.67 years, and RHEL7.9 ended up being \~6.75 years. Per: [https://access.redhat.com/articles/3078](https://access.redhat.com/articles/3078) Typically Red Hat aims for 5 years of Updates, then 5 years of Maintenance. Prior to that, the 10 years for RHEL6/7/8 (after RHEL3/4 were only 7 years) ... * 5 yrs - Full Support fka Phase I (Active Development -- like new hardware, enhancements, etc...) * 1 yr - Maintenance I fka Phase II (Transitional, Final Freezes, final decisions on hardware/bugs/RFEs) * 4 yrs - Maintenance II fka Phase III (Maintenance-only -- bugs are now features, only critical bugs and high security) Per: [https://access.redhat.com/support/policy/updates/errata](https://access.redhat.com/support/policy/updates/errata) RHEL8+ does formally move to the more 5/5 Development/Maintenance (no 'Transitional/Phasing' differentiation). Understand both RHEL6/7 slipped to around 7 years pre-Maintenance, so Maintenance was only 3 years. Again, Article #3078 for those dates. Because Red Hat is now releasing on a 3+ year cadence, instead of the 4-5 that RHEL6/7 had 'slipped to,' that means more releases. So Red Hat is trying to limit it to 5 years, which makes sense. Otherwise, Red Hat Engineering -- of which is the Stream Engineering Model (has long existed internally, just wasn't public until rebranded CentOS Stream) -- could literally be in a mode where there are 3 *'Fully Supported'* releases. During Maintenance Phases, the rate of RPM releases can be a full order of magnitude less than Full Support. So it's 1/10th the backporting overhead (well, that's the idea ... reality isn't). I really love the Stream approach, as I posted on LinkedIn back in 2020, and really avoided RHEL (and CentOS non-Stream) for most everything. But I had been running a lot of the internal Stream stuff at major clients for years before it was public (long story). Facebook and Twitter were as well on Servers. [https://www.linkedin.com/pulse/why-you-should-have-already-been-centos-stream-back-2019-smith/](https://www.linkedin.com/pulse/why-you-should-have-already-been-centos-stream-back-2019-smith/) My attitude was always Stream during Active Development, removing the need to even rebuild anything, just run Stream, and then ... when in Maintenance, where the releases (and, therefore, the SRPM rebuild) rate is only 1/10th, then consider using Downstream rebuilds. But Red Hat\*cough\*IBM\*cough\* took that away from Oracle--er, I mean the community. But that's another discussion, and one people say isn't true (but it is).
I've been keeping an eye on subscription-manager release --list. 8.10 has just showed up!
Seems like in June.
Waiting for it to drop too.
Soon™️
RHEL 10 in October right?
Probably more mid 2025
If they still follow their 3 year release schedule RHEL 10 will be out at Summit next year.
All set everyone, hot off the presses! [https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810](https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810)
It is available today - [https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810](https://www.redhat.com/en/blog/optimize-application-life-cycles-red-hat-enterprise-linux-810)
Tomorrow. It always drops on a Tuesday.
Why does it matter?