Thoughts on Fedora Server lifecycle

[Miloslav Trmač]

On Fri, Nov 1, 2013 at 7:30 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> At Fedora 22, we release "Fedora Server 1.0 Preview 2", with the same
> caveats. However, at Fedora 23, we release "Fedora Server 1.0". At
> this time, we agree to freeze the interfaces and make clear demands on
> backwards-compatibility. For the remaining life of Fedora Server 1.x,
> it will be a stable platform (and understood to be extremely
> conservative with its updates).
<snip>
> Fedora 25 would offer the "Fedora Server 1.2" updates roll-up and
> "Fedora Server 2.0 Preview 2", and finally Fedora 26 would offer only
> "Fedora Server 2.0" as install media. At this time, Fedora Server 1.0
> would become "security-fixes only" for the six months until Fedora
> Server 2.1 (to allow overlap to upgrade). As of Fedora Server N.1 of
> any release, the N-1 series is abandoned.
>
> So yes, that sounds ambitious, but what do you think of the idea?

As an ideal state, I'd prefer "updates always work" (at least for the
smaller set of preferred setups, e.g. "this is the Fedora Server LDAP
server" recipe we've been talking about previously) because that gives
us something very close to the holy grail: only one branch to manage,
and an effectively infinite lifetime.  However I realize that even
with the restriction to a few limited recipes we may not be able to
pull this off.


So, to address this specific proposal, because it only requires us to
maintain (1+1/18) production branches at a time, it might be
significantly more feasible than the other past proposals.   I think
the following would be necessary:

* Base WG and Envs/Stacks WG solving the "language runtimes/ABI"
problem, to make sure Server N.2 is still relevant for new
applications while not breaking applications deployed to server N.0.
(We kind of need to have it solved anyway, but the current frequent
releases hide the worst aspects of the problem by giving users 2
versions to choose from.)

* Some test automation to give everyone confidence in the N.{1,2} versions.
     Mirek