Fedora Final Release

Update FedoraPreviousPrevious.yaml in ansible repository

Set the variable to True in ansible repository.

Koji changes

$ koji edit-tag --lock f39
$ koji edit-tag --lock f39-modular

Bodhi Changes

Set the bodhi release to current

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

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

$ bodhi releases edit --name F39 --stable-tag f39-updates

Set EOL of oldest release to corret date

$ bodhi releases edit --name F37 --eol YYYY-MM-DD
$ bodhi releases edit --name F37C --eol YYYY-MM-DD
$ bodhi releases edit --name F37F --eol YYYY-MM-DD
$ bodhi releases edit --name F37M --eol YYYY-MM-DD

Ansible Changes

Disable Branched Compose

Now that we have a final GOLD compose, we dont need nightly branched composes anymore. This is disabled in releng role in infra ansible repo and then running the playbook.

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

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 40 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. cloud-updates: Remove the commented version and append a new entry for 39.

  2. container-updates: Remove the commented version and append a new entry for 39.

  3. Update FedoraCycleNumber to 39.

  4. Update FedoraBranchedBodhi to current.

  5. Set FedoraPreviousPrevious to True.

For the references, checkout this PR.

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, 39.

  2. ComposeID: The ID associated with the Compose, such as "Fedora-39-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-39" or "fedora-39-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 39 Fedora-39-20160614.0 39_RC-1.2 fedora-39 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 mirror-admin@lists.fedoraproject.org list.

Check and set EOL on previous releases to reflect reality

  1. check PDC for active releases and respective EOL date

  2. if needed run the adjust-eol-all.py script from releng repository to correct any mistakes

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.

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