Packit: A Guide To Releasing New Versions

by Admin 42 views
Packit: A Guide to Releasing New Versions

Hey everyone! So, you're looking to make a new release of Packit, huh? Awesome! It's a pretty straightforward process, but like anything, there are a few key things to keep in mind to make sure everything goes smoothly. We're going to break down the entire release checklist for you, step-by-step. Think of this as your ultimate cheat sheet for getting those sweet new versions out the door. We'll cover everything from the initial caution notes to the final celebratory emoji. So, grab a coffee, settle in, and let's get this release party started!

Important Pre-Release Considerations

Before we dive headfirst into the release workflow, let's talk about something super important: compatibility. You absolutely cannot release Packit version 1.0.0 or later to Fedora releases that have already hit their stable point by the time 1.0.0 is out. This means, for 1.0.0, Packit CANNOT be released to any Fedora version less than or equal to 41, and EPEL versions less than or equal to 9. This is a critical rule to avoid breaking things for users on those older, stable releases. Always double-check the target Fedora and EPEL versions against the release timeline. It’s better to be safe than sorry, right? We want everyone to have a good experience with Packit, and that starts with making sure our releases don't cause unexpected issues for our users.

We also need to make sure all our RPM-packaged projects are ready for the new release. Take a moment to check the status of:

Ensuring these dependencies are up-to-date and compatible is a crucial part of the release process. Think of it like building a sturdy house – you need to make sure the foundation and all the supporting beams are solid before adding the roof!

Step-by-Step Release Guide

Alright, let's get down to the nitty-gritty of actually making the release. Follow these steps carefully, and you'll be a release pro in no time!

1. Pending Updates and Karma Check

First things first, make sure any pending updates have made their way to stable in Bodhi. If not, you might need to ask team members for karma and patiently wait for those updates to be approved and pushed. This ensures that any immediate dependencies are met before you introduce a new version of Packit. It's all about a smooth dependency chain, guys!

2. Prepare the New Release Workflow

Now, it's time to kick off the automated release preparation. Head over to the Prepare a new release workflow in the Packit repository. Click the Run workflow button. You'll need to select the main branch and then enter the correct version number for your new release. Once you hit that button, the workflow will run, and it should automatically create a pull request in the repository. This PR is where all the magic starts to happen – it prepares the release notes and other necessary files.

3. Review the Pull Request

This is a super important step! Once the PR is created, you need to review it thoroughly. Don't be shy about asking other team members to help you out, especially with checking the changelog grammar and making sure everything reads well. You can even check out the PR locally, make any necessary tweaks, and then push those changes back to the upstream repository. This is your chance to polish everything up before it goes live.

Handling the Check release notes Check

Sometimes, the Check release notes required check might not run automatically. If you encounter this issue (like in issue #13), don't panic! A simple force-push to the branch or editing the PR description should trigger the check. Just keep an eye on it and nudge it if it seems stuck.

4. Merge the Pull Request

Once you're happy with the content of the PR and there are no pending review requests, it's time to merge it! This merge action is designed to trigger the next crucial step in our release process.

5. Publish the GitHub Release

Merging the PR should automatically initiate an action (details here) that creates a draft release in the releases list. Your job now is to edit this draft release, give it a final once-over to ensure all the content is accurate, and then hit that Publish release button. Congratulations, you've officially released it on GitHub!

6. Upload to PyPI

Next up, we need to make sure the package is available on PyPI. Verify that the package has been uploaded successfully to PyPI. This makes it easily installable for everyone using Python package management.

Handling RPM-Specific Releases (Fedora & EPEL)

Now, let's talk about the slightly more complex part: dealing with RPM packages for Fedora and EPEL. This requires extra attention, especially with the version constraints we discussed earlier.

Critical Caution for Older Releases

Seriously, do not merge dist-git PRs for the Packit project and older releases (F40, F41, EPEL9). These PRs are opened because of this bug. Merging them on older, stable releases can cause a lot of headaches. Always keep this bug report in mind when working with older Fedora and EPEL versions.

Merging Dist-Git PRs

After a few minutes, you'll need to check and merge the PRs in dist-git that were created by Packit. Here’s how to handle them:

  • Check Consistency: First, ensure that both the stage and production instances of Packit proposed the same set of changes. This consistency check is vital.
  • Merge Stage PRs: Merge the PRs created by the stage instance that use the pull_from_upstream command. This action will automatically close the associated Bugzilla ticket from Upstream Release Monitoring, which is super handy.
  • Close Production PRs: For the PRs created by the production instance, you should close them, along with the production pull_from_upstream PR. This specific handling is due to the bug mentioned earlier and ensures we don't disrupt stable environments.

Satisfying Dependencies with Sidetags

If you haven't released all three core packages (Packit, ogr, specfile), you need to make sure our sidetag has up-to-date builds for all of them. To do this, you'll need to comment /packit-stg koji-tag --all-branches in any dist-git PR for any package that hasn't been released yet. This command essentially tells Packit to pull the latest builds for those packages into the sidetag, satisfying any dependency requirements. This will then trigger Koji builds and potentially Bodhi updates. For instance, if you're only releasing ogr, you'd need to comment this command once in a packit dist-git PR and once in a specfile dist-git PR.

You can monitor these jobs on the Packit dashboard.

Verifying Koji Builds and Bodhi Updates

After the sidetag updates and PR merges, give it a few minutes and then verify that the RPMs have been built in Koji. You can check the build status for:

Once the Koji builds are confirmed, wait a bit longer and then check that the updates have been created in Bodhi. You can find these by searching for packit on the Bodhi updates page.

Celebrate Your Success!

And that's it, folks! You've successfully navigated the Packit release process. Take a moment to bask in your glory. You've done a great job ensuring a smooth and stable release for everyone. Time to celebrate!

🚀🎉