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

[Jason Brooks]

On 11/06/2012 10:34 AM, Matthieu Gautier wrote:
> 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.

It's an interesting idea -- right now, at any one time, there are two 
supported releases: the latest and the latest minus one, both with 13 mo 
life spans.

If you want to move fast, you're always going to be on the latest 
release (or the alpha of latest +1).

If you don't want to move fast, chances are that latest -1 isn't slow 
enough to satisfy you.

For those who upgrade each release (or sooner), a 6mo life span for the 
latest release wouldn't matter. Those who don't want to upgrade every 
six months might well appreciate the two year life span.

>
> 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.
>


-- 

@jasonbrooks