deb-mock/docs/Releasing-Mock.md

layout	title
default	How do we release Mock

Mock versions

We keep the "major.minor" versioning scheme, and we bump the "major" number when some important/notable new feature appears, or when breaking change happens.

For the mock-core-configs package, the major number reflects the latest Fedora branched version from Rawhide.

Note we maintain multiple Mock versions in parallel. See README.md file for more info. You might need to repeat the steps described in this document multiple times. Even though tito should have appropriate releasers configured, please be careful when updating various distributions and use the correct branch version.

Fedora Rawhide branching

When you plan to release a new mock-core-configs for a new Fedora version being branched from Rawhide, there's a script in releng/rawhide-branching.sh that helps you to setup a correct configuration layout.

For Rawhide releases, you'll primarily be updating mock-core-configs only. Follow the steps in the release checklist, but focus only on the mock-core-configs parts. Be sure to use the --config-only flag when generating release notes.

Release checklist overview

0. Make sure all GitHub CI checks are passing for the latest commit

1. Change to the correct local branch, e.g. main

    $ git checkout main
   

2. Fetch git remote, and propose local-only patches (if any)

    $ git pull --rebase main
   

3. If you want to propose the release through a PR, switch to a new branch

    $ git checkout -b release-2024-05-15
   

4. Prepare release notes. Use the going-to-be-released version, not the current version.

   For a full release (both mock and mock-core-configs):

    $ sudo dnf install towncrier
    $ ./releng/generate-release-notes --use-version 5.1
    $ vim docs/Release-Notes-5.1.md  # modify manually!
   

   For a mock-core-configs only release:

    $ ./releng/generate-release-notes --use-version 40.3 --config-only
    $ vim docs/Release-Notes-Configs-40.3.md  # modify manually!
   

   Don't forget to manually modify ./docs/index.md and mention the new release.

   Add list of contributing authors:

   For mock: $ git log mock-4.1-1..HEAD --format="%aN" mock/ | sort | uniq

   For mock-core-configs: $ git log mock-core-configs-38.1-1..HEAD --format="%aN" mock-core-configs/ | sort | uniq

5. Commit all the pending changes

6. On your box (you need push-access rights), tag the git tree:

   For a full release (both mock and mock-core-configs):

   # First tag mock-core-configs
   $ cd ./mock-core-configs
   $ tito tag --use-version 40.3  # major.minor according to policy
   
   # Then update mock's spec and tag mock
   # Update 'Conflicts: mock-core-configs < ??' in mock.spec
   $ cd ./mock
   $ tito tag --use-version 5.1  # major.minor according to policy
   

   For a mock-core-configs only release:

   $ cd ./mock-core-configs
   $ tito tag --use-version 40.3  # major.minor according to policy
   

   For a mock only release:

   $ cd ./mock
   $ tito tag --use-version 5.1  # major.minor according to policy
   

7. Push the tito-generated commits to the upstream repo

   Suggestion: You can calmly avoid doing direct pushes. You can simply remove the local-only git tag created by tito, and submit PR the normal way:

   $ git tag -d mock-4.1-1  # drop tag
   $ git branch new-version proposal
   $ git push yourremote new-proposal
   ...
   remote: Create a pull request for 'new-proposal' on GitHub by visiting:
   remote:      https://github.com/praiskup/mock/pull/new/new-proposal
   ...
   

   These tito-generated commits can calmly be squashed, updated, etc. (you may include documentation fixes there). Just don't forget to re-add the dropped tag back (if dropped) 'git tag mock-4.1-1'. Alternatively just git push the commits.

8. Push the git tags upstream, e.g.

   For mock-core-configs: $ git push origin mock-core-configs-40.4-1

   For mock: $ git push origin mock-5.1-1

9. Release for EPEL and Fedora

   $ # make sure that .tito/releasers.conf is up to date

   For mock-core-configs: $ cd ./mock-core-configs $ tito release fedora-git-all

   For mock: $ cd ./mock $ tito release fedora-git-all

10. publish tgz

    • The tito release calls above uploaded the tarball to Fedora DistGit lookaside cache. You can simply use those. Alternative you should be able to generate the same (byte-by-byte) tarball via tito build --tgz

    • Go to the releases page,

    • click "Draft new release"

    • Choose existing tag. E.g., mock-1.4.9-1 @ main

    • Enter the same tag as release "title"

    • Attach the tarball binary

11. Once the builds finish (successfully) you should push the just built packages to their respective testing repositories. This can be done either with the Bodhi WebUI at https://bodhi.fedoraproject.org/ or if there are no other package dependencies, using the 'fedpkg update' command (you can specify multiple builds, even for multiple fedora/epel versions, like [mock-1.35-1.fc38, mock-1.35-1.fc37, ...]). Note that you do not need to do this for the Fedora Rawhide build since it automatically gets pushed to testing.

12. Announce the release

    We typically send announcement e-mails to bulidsys@lists.fedoraproject.org, and depending on the severity of the release also to devel@lists.fedoraproject.org.

    We also announce in Fosstodon CPT's space.

    For a full release (both mock and mock-core-configs):

    Subject: Mock v4.0 released (and mock-core-configs v38.5)
    
    Hello maintainers!
    
    I'm glad I can announce that we have a new release of Mock v
    (the chroot build environment manager for building RPMs).
    
    <SHORT SUMARY ann LIST OF IMPORTANT CHANGES>
    
    Full release notes:
    
        https://rpm-software-management.github.io/mock/Release-Notes-4.0
    
    The updated packages are in Bodhi:
    
    [Fedora 38]:
    [Fedora 37]:
    [EPEL 9]:
    [EPEL 8]:
    
    Happy building!