There Is Now A Proposal For Shifting Fedora To An Annual Release Cadence

[dungeon]

And Debian admins are like: A new release every year?? Why the rush..

Debian does not have fixed release cadence , it just aim at about 2 years cadence, but only release once it is ready:

Release statistics

Version	Code name	Freeze length	Time from previous release	Time from next release up to EOL	Total lifetime
1.2	Rex		178 days
1.3	Bo		175 days
2.0	Hamm	171 days	414 days
2.1	Slink	125 days	228 days	76 days	601 days
2.2	Potato	212 days	525 days	346 days	1049 days
3.0	Woody	383 days	703 days	389 days	1442 days
3.1	Sarge	34 days	1053 days	357 days	1028 days
4.0	Etch	258 days	671 days	366 days	1044 days
5.0	Lenny	202 days	678 days	365 days	1087 days
6.0	Squeeze	184 days	722 days	391 days
7.0	Wheezy	308 days	818 days	367 days
8.0	Jessie	171 days	721 days
9.0	Stretch	224 days	784 days

https://wiki.debian.org/DebianReleases#Release_statistics

[dungeon]

Boring unapporoved again Do not ask me how much Debian Freeze will be, maybe you could conclude something from past statistics

[lsatenstein]

Fedora, keep a previous release supported for longer. Fedora keep F28 for one year from the F29 date. And run F31 as a rolling release. This way we satisfy most groups of users. Those who want snapshot and LTS and the ones who want to be on the bleeding edge. Fedora could do well to emulate SUSEs Tumbleweed rolling release concept and their biweekly full DVD release. Tumbleweed so has a network install version, a live ISO and a DVD iso.
While I am a Fedora user for years, follow Tumbleweed / openSuse software mgt as a good model. It needs some review.

My Tumbleweed experience has been very positive. Monthly, I download their latest DVD, which can be used for offline institute/recovery.

[lsatenstein]

Is IBM putting the pressure on RedHat to trim staff, ergo switch to annual releases. There would be cost savings as fewer staff to do the docs, and more in-depth testing.

BTW, I am for the Arch/Tumbleweed/Solus/Manjaro maintenance model.

[nanonyme]

The real problem here is of course that this would disconnect Fedora with Mesa and LLVM release cycles so you'd have fairly old drivers for last six months

[nanonyme]

Solus uses a rolling release scheme as well, but they test everything very well before pushing it through people's throats. Manjaro does the same (although to a lesser extent). Fedora could do the same they do.

You might still break user's flows. A distro essentially provides SDK for compiling against that distro. Most distros try to provide stable ABI for SDK for a given release. When that stable ABI starts meaning "okay, we need to build another LLVM in", it eventually starts hurting a lot.

[re:fi.64]

Is IBM putting the pressure on RedHat to trim staff, ergo switch to annual releases. There would be cost savings as fewer staff to do the docs, and more in-depth testing.

I seriously doubt this... This isn't even a confirmed proposal, just a random idea.

[srakitnican]

Quite the opposite. If you follow mailing list thread, the argument against LTS release is that it is more difficult to maintain then to just release every 6 months whatever major version upstream is serving.