Go to the maintainer-tools repository, clone the repository and run
pip install -r requirements.txt in order to get all the dependencies to be able to execute the
It's also advised to set a GitHub personal access token, otherwise you might run into API usage quotas. Go to Personal access tokens on GitHub and create a new token with scope
public_repo. Now, create a new packit user configuration at
~/.config/packit.yaml and paste there the following content:
authentication: github.com: token: [YOUR_GITHUB_PERSONAL_ACCESS_TOKEN]
Note: Upstream releases are done automatically on a fortnightly alternating schedule, meaning one week we release osbuild and then the next week we release osbuild-composer.
Navigate to your local repository in your terminal and call the
release.py script. It will interactively take you through the following steps:
Gather all pull request titles merged to
mainsince the latest release tag
Create a draft of the next release tag
While writing the commit message, keep in mind that it needs to conform to both Markdown and git commit message formats, have a look at the commit message for one of the recent releases to get a clear idea how it should look like.
Push your signed git tag to
From here on a GitHub composite action will take over and
- Create a GitHub release based on the tag (version and message)
- Bump the version in
- Commit and push this change to
mainso the version is already reflecting the next release
Then our fedora-bot takes over and performs the remaining steps:
- Get a kerberos ticket by running
fedpkg buildto schedule Koji builds for each active Fedora release (or: dist-git branch)
- Update Bodhi with the latest release
If you are a Red Hat employee, please continue reading about this in our internal release guide.
The last of releasing a new version is to create a new post on osbuild.org. Just open a PR in osbuild/osbuild.github.io. You can find a lot of inspiration in existing release posts.