I’m not sure I understand the question. Can you please elaborate on this? Rocky Linux 8 in this case would refer to the current latest/supported version as noted in current supported releases.
As an example.
Rocky Linux 8.10 is the only supported minor version supported. When 8.10 was released, it superseded 8.9. This means 8.9 is not supported. See the unsupported version example.
Between May 31, 2024 and May 31, 2029, the only supported, maintained version of Rocky Linux 8 is 8.10. Rocky Linux 8, as a whole, goes completely end of life on May 31, 2029. See the an end of life release example.
hi, nazunalika
When a new minor version is released, the previous minor version is EOL。
We need to make a downtime plan to upgrade the minor version。
This may happen several times a year.
If we take the EOL time of major version as a reference, for business continuity considerations of server. We don’t need to plan downtime frequently to upgrade minor versions.
The EOL time for major versions at May 31, 2029, We just need to make a downtime plan and upgrade the major version before this time.
So, this is our idea. I want your advice.
Enterprise policy requires that the EOL of OS need be upgraded.
minor version is updated, and the old minor version is EOL, so the OS needs to be shut down for maintenance many times.
We want to reduce the number of downtime operations caused by EOL
I believe there’s some confusion, since you’re focusing too much on the EOL dates of both the minor versions and major versions of Rocky Linux. I think focusing too hard on the dates is missing the bigger picture: keeping your systems up to date should always be a priority.
Long story short: You should always keep your system up to date, regardless of the end of life dates. We actively do not support outdated systems or old releases.
My thoughts:
There’s going to be updates that will come in that fix vulnerabilities or fix bugs. Some of those require reboots (a new kernel update requires a reboot). An enterprise policy of EOL systems having to be migrated is fair and more enterprises should have them. However, that should not be used to dictate your patching cycle, given that updates come out at least weekly. Instead, EOL dates should be used as a guide, rather than a rule of system patching and downtime. That is something to consider when designing a patching schedule with your team and stakeholders of the enterprise.
If you want to reduce the amount of downtime and rebooting, you will need to come up with a compromise that you, your team, and enteprise stakeholders all can agree on that will not leave your systems full of bugs and security vulnerabilities. Most clients I’ve had have employed a monthly patching cycle, which involves updating the systems fully using dnf update (or otherwise) and rebooting the systems.
A major version EOL date would be what I would care about only in the case of migrating systems to a supported version and decommissioning those old versions. I would never consider any EOL date as a basis for system maintenance.
Someone else may have different thoughts on this, but that is how I look at it.
New “point update”, minor version, arrives about twice a year. It adds new features (in addition to fixes). The spurious, “unscheduled” updates between point updates are basically all fixes (for vulnerabilities and bugs).
The Rocky 8 has already reached its last point update; anything that it will get between now and 2029 will be a vulnerability or critical bug fix. These should be “easy” for maintenance; just do dnf up and reboot (if necessary).
A “stability principle” of Enterprise Linux is that even the addition of features (by point updates) should not affect existing setups negatively. (There can be exceptions, but they are rare.)
You can always have test systems, where you apply updates first, before the production systems.
That way surprises do not get into production.
A question is, how long does it take to reboot a system, and how much does that downtime affect your services?
If your service cannot tolerate even a short break, then you do need some high availability (HA) setup, where service is provided by more than one system and thus taking one of them down will not interrupt the service. Then you can update and reboot all of them, one at a time.
As for EOL (of Rocky 8), one is expected to setup a new server, probably Rocky 10 or 11, well ahead of 8’s EOL so the service can migrate, uninterrupted, by the time the 8 must go. If you do already have HA, then replacing legs of it ought to be relatively trivial.