Fedora Final Release

Koji changes

$ koji edit-tag --lock f41

Bodhi Changes

Set the bodhi release to current

$ bodhi releases edit --name F41 --state current

Set the bodhi stable tag to point to updates instead of base repo

$ bodhi releases edit --name F41 --stable-tag f41-updates

Set EOL of oldest release to correct date

$ bodhi releases edit --name F39 --eol YYYY-MM-DD
$ bodhi releases edit --name F39C --eol YYYY-MM-DD
$ bodhi releases edit --name F39F --eol YYYY-MM-DD
$ bodhi releases edit --name F39M --eol YYYY-MM-DD

Atomic desktops changes

Run the releng scripts/update_ostree_refs.sh on a compose machine with /mnt/koji/ mounted.

$ scripts/update_ostree_refs.sh 41

This updates the refs for Atomic desktops to have users follow updates for the new release rather than being stuck on the GA compose forever.

Ansible Changes

Lift RelEng freeze

Lift the RelEng Freeze so that the updates will be pushed to stable. This is done by editing RelEngFrozen variable in infra ansible repo and then run the bodhi playbook.

$ sudo rbac-playbook groups/bodhi-backend.yml

Update Release Versions

In pungi.rpm.conf.j2 we need to check that the release.version_int should be now pointing to 42 for all the artifacts that compose location is going to be under /compose/branched/. For the reference pungi.rpm.conf.j2 check.

Update releng roles updates

  1. Set FedoraCycleNumber to 41.

  2. Set FedoraBranchedBodhi to current.

  3. Set FedoraPreviousPrevious to True.

  4. Set FedoraBranched to False.

Now run the releng-compose playbook:

$ sudo rbac-playbook groups/releng-compose.yml

For the references, checkout this PR, though note it is somewhat old and includes some things that are no longer needed, and leaves out some that should be done.

Stage Final Release for Mirrors

To prepare for running the staging script, make sure you have the following information:

  1. Release Version: This is the numerical version number of the release, for example, 41.

  2. ComposeID: The ID associated with the Compose, such as "Fedora-41-20160614.0".

  3. Label: The label used for the location in stage, for example, "Compsoe label for the location in stage 39_RC-1.2."

  4. Key: The name of the release key, which can be "fedora-41" or "fedora-41-secondary," as examples.

  5. Prerelease: Set this to 0 or 1 to determine if the release should be placed in a testing environment or not.

  6. Arch (Optional): For secondary architectures, this parameter can be used to make changes to some internal locations.

    $ scripts/stage-release.sh 41 Fedora-41-20160614.0 41_RC-1.2 fedora-41 0

  7. Sync the release to the Red Hat internal archive following internally documented

Make sure to grab the directory size usage numbers which is used to send an email to [email protected] list.

Check and set EOL on previous releases to reflect reality

Check Bodhi for active releases and set respective EOL date. It’s important to have an EOL date set, because it serves for other scripts to distinguish between stable and branched releases.

Make sure there are no tagging leftovers from bodhi

Sometimes builds are not properly tagged during the freeze process. Make sure all builds are properly tagged, for more info about the [issue](https://pagure.io/releng/issue/11775)

Verification

Verification is somewhat difficult as one cannot look at the content via the web server due to permissions. Typically we ask somebody from the Infrastructure team to give the tree a second set of eyes.

Post Release

One Week After the Release

In the first week after the release MirrorManager still uses the files at fedora/linux/development/<version> and not at fedora/linux/releases/<version>

Once enough mirrors have picked up the files in the release directory, run the following playbook from batcave to change the paths in MirrorManager:

$ rbac-playbook -v /srv/web/infra/ansible/playbooks/manual/mirrormanager/move-devel-to-release.yml --extra-vars="version='42'"

Want to help? Learn how to contribute to Fedora Docs ›