Server/Proposals/Server Lifecycle

Resources

This proposal comes from the following thread started by Stephen Gallagher on the server mailing list:

Thoughts on Fedora Server lifecycle

A relevant earlier proposal that is similar is Tom Callaway's Overhauling the Fedora Release Model talk from FUDCon Lawrence in January 2013.

Overview

This proposal is for a lifecycle of eighteen months (with slight extensions for slippage) as follows:

• We will start with Fedora Server 1.0 (rather than Fedora Server 21).
• We would build the Base Design as Fedora 21, Fedora 22 and Fedora 23 following mechanisms not terribly dissimilar to the present-day model.
• We would then create the Fedora Server atop this, delayed by a small amount < 1 month).
• We would use the latest Fedora Base bits as the platform and sync our pieces atop it at regular intervals, aiming for a finalized release every eighteen months.
• Up until the final release, each N preview release should be just a snapshot matching EXACTLY the Fedora Base release at that time. It should be usable (but probably won't get any extra QA time over the Base release). Then at the N.0 final release, it should get branched away and kept more tightly controlled. This doesn't mean that it can't get updates out of the Base branches, but they should be merged in when they're ready, not blasted in from the firehose.
• Each N.0 release essentially goes into maintenance mode at the moment of it's stable release. Real new functionality should head to N+1 previews and only get pulled back to N.x if it makes sense and someone is willing to do the work.

Detailed Walkthrough Of Timeline

Source SVG

• Let's start the discussion from Fedora 21. We would follow the Fedora 21 process closely until the base design is declared final (much as current Fedora is now). Ideally at the same time (but possibly delayed by up to a month), we would release "Fedora Server 1.0 Preview 1". This would be a complete, installable server operating system, but make it clear that it's a preview release that may not represent the final product.
• 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).
• At Fedora 24, we now release two things: "Fedora Server 1.1", which will just be an updated installer with the latest versions of any package updates that have occurred in the standard install since Fedora Server 1.0". We will also release "Fedora Server 2.0 Preview 1", following the same guidelines as above.
• Fedora 25 would offer the "Fedora Server 1.2" updates roll-up and "Fedora Server 2.0 Preview 2."
• 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.

Questions & Answers

1. How would you handle upgrades between N-1 -> N ?
   • Well, that's part of the point of the .1 releases too. That's the point at which we should be re-testing fedup to major releases. Within a release, fedup shouldn't (must not?) be required. I.e. Fedora Server 1.0 -> 1.1 should be safe and clean with just 'dnf update', but 1.1->2.0 should go via fedup. (sgallagh)
2. Is Fedora Server going to have its own package repository?
   • Yes, the same way that Fedora 19 and Fedora 20 have different repositories. It's nothing new. (sgallagh)
   • This is quite a bit different, in that it's not tracking a fedora release. This would potentially mean "yet another" target for builders and 3rd party repos to support. I would much rather track the current fedora releases with better packaging, usability etc than spawn an entirely new structure. (Evolution)
3. In Fedora Server 1.0 you will have to install packages built for Fedora 21, however if the product that produces them stays on a short release cycle, by the time we go 1.0 there not even security updates anymore for them. So what do we do ? We force other products to do security updates for 24 months ?
   • Up until the final release, it really should be just a snapshot matching EXACTLY the Fedora Base release at that time. It should be usable (but probably won't get any extra QA time over the Base release). Then at the N.0 release, it should get branched away and kept more tightly controlled. This doesn't mean that it can't get updates out of the Base branches, but they should be merged in when they're ready, not blasted in from the firehose. (sgallagh)