New release cycle proposal (was Rolling release model philosophy (was ...))

Matthieu Gautier mgautier at fedoraproject.org
Tue Nov 6 18:34:45 UTC 2012


Hello all,

I'm not a Fedora developer, nor package maintainer. I'm a French Fedora
Ambassador for a long time. (I should say "I was" cause I don't do to
many things last time, just wake up every 6 months for Fedora releases
and other events).
I'm also a developer but that's not about Fedora.

While reading this thread, an idea came to me about the Fedora release
cycle.

First, while discussing with fedora users, from events, friends, and
parents (real Adam's uncle Bob), the following points can be inferred:
 - They like the blending edge part of Fedora.
 - They want stable releases.
Not always in the same time, it's depending of user profile. It seems a
little antagonist, but that's what they want.
(By the way, they are mostly happy with Fedora)

What I propose is a new release cycle: One release every year and a
"preview" (not sure of the name) release between them.
- Small features can come in whatever release.
- Big features (libc, anaconda, systemd, gnome3, wayland...) can come in
preview release only.
- FedoraN releases have a lifetime of 2 years.
- FedoraNPreview releases have a lifetime of 6 months.

For example, if we start from Fedora20 at beginning of 2014:
- Fedora20(jan 2014) is a stable release. (Fedora18 eol, actual way of
doing)
- Fedora21Preview(jul 2014) is an "unstable" release. (Fedora 19 eol)
- Fedora21(jan 2015) is a stable release. (Fedora21Preview eol, new way
of doing)
- Fedora22Preview(jul 2015)
- Fedora22(jan 2016) (Fedora22Preview and Fedora20 eol)
- Fedora23Preview(jul 2016)
- Fedora23(jan 2017) (Fedora23Preview and Fedora21 eol)
- ...

Preview version doesn't mean unstable. It means version as we have now,
but more tolerant to bug ("Here the new version of Fedora with latest
features. We make our best, but maybe not enough. You're aware of it.")
Stable version is mainly preview version stabilized plus other (small)
features.


For users:
- Users wanting stable (long time support) version can install it every
2 year.
- Users wanting new versions but stable can install it every year
- User wanting blending edge can install a version every 6 months

For devs:
Still a version every 6 months, new features can still be added. Just
one out of two versions has to be more stable (no big feature)

For QA:
Still a version every 6 months. More QA for stable versions

For Ambassadors/Marketing:
Still a version every 6 months. Nothing change.

For maintainers/packagers:
For now there are 4 versions at the same time: Fn-1, Fn to maintain and
Fn+1, Rawhide in dev
With my proposition:
- Between Fn and Fn+1prev: 2 versions (Fn-1, Fn) to maintain and 2
versions (Fn+1prev, rawhide) in dev
- Between Fnprev and Fn: 3 versions (Fn-2, Fn-1, Fnprev) to maintain and
1(2) version (Fn, rawhide) in dev
During 6 months, there is one version more to maintain, but changes
between Fnprev and Fn are not breaking stuff.

We could also create some king of "half end of life" : stable releases
get all updates for 1 year, and security updates only for the second
year. This could reduce maintainers' work.

This way we reach the two worlds:
- Users can chose the version they want (long time support, stable,
blending edge)
- Usual dev work for preview versions, but less QA (We have to admit it)
- Usual QA for stable version, but less dev
- Number of versions to maintain doesn't explode.
- We can have versions more rough, simplifying dev and still allowing
"real" user feedback.
- External editors could base their products on stable versions and skip
preview ones.

What do you think about this ?

Regards,
Matthieu Gautier.



More information about the devel mailing list