# 20210426 jlebon session # What Joe Wrote: https://github.com/coreos/fedora-coreos-tracker/issues/785 It would be nice to have end user documentation of the cadence that we follow for releasing new version of FCOS. Particularly w/r/t Fedora moving between major releases. Here are some example copy of what a release cadence guideline could be: *Scheduled Releases* We release new versions of the production streams every two weeks. We release new `next` versions on X date of the month. This release in `next` stays for Y weeks before being promoted to `testing`. `testing` streams get promoted to `stable` after Z weeks in `testing`. These timeframes are just guidlines we try to follow for doing releases. They may be delayed if we are seeing issues with packages that need to be sorted out before doing a new release. You can see all blocking issues on our issues tracker under the `release blocker` tag. *Ad-Hoc Releases (Bugfix/Security)* If there are important bugfix or security updates the FCOS team will issues releases on a case per case basis and these releases will be communicated on the mailing list and you can follow security issues under the `security issue` tag. *Fedora Major Version Rebases* For rebasing on the next version of Fedora we follow the following cadence. When the next release of Fedora hits Beta we rebase the `next` stream on that release. When the Fedora Beta hits GA we will do a release on `testing` in 2 weeks or so after that date. In another two weeks we will move `testing` to stable. This copy is just an example. The time frames are made up and open for discussion. This document would allow us to help set some expectations for users on when to see new releases of FCOS while allowing for us to be flexible with our releases to account for stability issues within our core package set. # For Fedora 34 we are doing: - Week 0 (GA): next release with bumped content - Week 1: testing release based on last next - Week 3: stable release based on last testing # Current Design.md ## Release Streams - Originally discussed in [#22](https://github.com/coreos/fedora-coreos-tracker/issues/22). ### Production Refs Fedora CoreOS will have several refs for use on production machines. At any given time, each ref will be downstream of a particular Fedora branch, and will consist of a snapshot of Fedora packages plus occasionally a backported fix. - `testing`: Periodic snapshot of the current Fedora release plus Bodhi `updates`. - `stable`: Promotion of a `testing` release, including any needed fixes. - `next`: The `next` stream represents the future. It will often be used to experiment with new features and also test out rebases of our platform on top of the next major version of Fedora. See [Major Fedora Version Rebases](#major-fedora-version-rebases) for more info. All of these refs will be unversioned, in the sense that their names will not include the current Fedora major version. The stream cadences are not contractual, but will initially have two weeks between releases. The stream maintenance policies are also not contractual and may evolve from those described above, but changes will preserve the use cases and intended stability of each stream. Users will be encouraged to run most of their production systems on `stable`, and a few percent of their systems on each of `next` and `testing` to catch regressions before they reach `stable`. ### Development Refs Development for the next `testing` and `next` releases will occur in development refs. These refs will be public, but will be stored in a different ostree repo from production refs. - `testing-devel`: Nightly build of the package set that will be snapshotted for the next `testing` release. - `next-devel`: Nightly build of the package set that will be snapshotted for the next `next` release. ### Mechanical Refs There will also be some additional unversioned refs for the convenience of Fedora CoreOS developers. These will be public and stored in the same ostree repo as development refs. Unlike production and development refs, mechanical refs are not curated; they're simply a snapshot of the corresponding Bodhi repos, with no package pinning and no backports of fixes. None of these refs are contractual; they might go away if we don't find them useful. - `rawhide`: Nightly snapshot of rawhide. - `branched`: Nightly snapshot of the upcoming Fedora release after it is branched. ### Out-of-Cycle Releases Due to the promotion structure described above, `stable` can contain packages that are as much as four weeks out of date. Sometimes, however, there will be an important bugfix or security fix that cannot wait a month to reach `stable` (or two weeks to reach `next` or `testing`). In that case, the fix will be incorporated into out-of-cycle releases on affected streams. These releases will not affect the regular promotion schedules; for example, a fix might sit in `testing` for only a few days before it is promoted to `stable`. If a fix is important enough for an out-of-cycle `stable` release, other affected release streams should be updated as well. In some cases it may make sense to apply a fix to `testing` but not issue an out-of-cycle release, allowing the fix to be picked up automatically when `testing` promotes to `stable`. ### Major Fedora Version Rebases The release process integrates with Fedora's release milestones in the following ways: - Fedora Beta Release - The `next` stream is switched over to the new release. - Fedora Final Freeze - The `next` stream switches to weekly releases to closely track the GA content set. - Fedora General Availability - Fedora CoreOS re-orients its release schedule in the following way: - Week 0 (GA release): triple release;`next` with latest Fedora N content - Week 1: triple release; `testing` release promoted from previous `next` - Week 3: triple release; `stable` release promoted from previous `testing`, now fully rebased to Fedora N. `next` and `testing` are now in sync. ### Deprecation Because production refs are unversioned, users will seamlessly upgrade between Fedora major releases, so compatibility must be maintained. Removal of functionality will require explicitly announced deprecations, potentially with long deprecation windows.