Ferrocene Documentation › Internal Procedures
Ferrocene logo

Internal Procedures

Release process overview

This section describes where the release process is implemented, how to change it, and how to publish new releases. Note that the high-level overview of the release process is present in the qualification plan. Make sure to read the overview before diving into this section.

Channel names

The release channel is determined automatically by the tooling, based on both the src/ci/channel file (managed by upstream) and the ferrocene/ci/channel file (managed by Ferrocene):

Release channel

src/ci/channel

ferrocene/ci/channel

nightly

nightly

rolling

pre-rolling

beta

rolling

rolling

stable

rolling

beta-${version}

stable

beta

stable-${version}

stable

stable

We rely on this approach of combining the two files to determine the channel (rather than storing the actual channel in ferrocene/ci/channel) to reduce the maintenance efforts.

This way, as long as we set ferrocene/ci/channel to “rolling” on the main branch, we don’t need to make any change ourselves to promote a branch from “nightly” to “pre-rolling” to “rolling”, as upstream does that for us when they change src/ci/channel.

Release Checklist

This checklist is targeted towards release managers who are running a release.

12 weeks before release

6 weeks before release

In any order:

Simultaneously, do the following in order:

  1. [release/1.NN] Branch beta.

  2. [KPs repo] Add the new version to the Known Problems database.

  3. Version Bump Release Notes.

    1. [main] Update the version in the release notes.

    2. [release/1.NN] Backport the release notes update, and remove :upcoming-release: from beta’s release notes.

    3. [main] Create a release note named next.rst.

5 weeks before release

In order:

  1. Perform another Documentation validation.

  2. Create a Semantic diff.

  3. [release/1.NN] Instruct the Safety Manager to sign the release branch.

  4. Deliver the documentation to the assessor.

At this point, the branch is in documentation freeze: no new PRs can be merged unless they do not affect the documentation signatures. In practice, only changes to CI are allowed from this point forward.

Note

If you do make a documentation change after this point, you MUST re-sign the docs and re-send them to the assessor.

When technical reports are received from the assessor

  1. Upload the technical reports

  2. [release/1.NN] Publish a dev release.

  3. Perform release validation.

At this point, the branch is in commit freeze: No commits at all can be made until the release is published.

Day of the release

After the release