Skip to content

Pulpcore Release Process

Here are the steps to take to release a Pulpcore version:

  • A new Y-releases must take all steps.
  • A new Z-release need only execute steps 2, 3, and 4.

Process

  • "I am releasing a new Y-branch of Pulpcore (e.g., 3.23)":
  • "I am releasing a new Z-release of Pulpcore (e.g., 3.23.0, 3.22.12)":
    • 2) Via the Github Actions, trigger a "Release pipeline" job by specifying the release branch (X.Y) and the tag (X.Y.Z) of the release.
    • 3) Once the release is available, make an announcement on Pulp discourse, in the "Announcements" category. See example.
    • 4) The CI automation will create PRs with the Changelog update and Versions bump that will need to be merged.
  • "I have released a new Y-release of Pulpcore, followup actions":
    • 5) Arrange for a new oci-image for that release by following the "oci-images Release Instructions".
    • 6) Update the ci_branches stanza in pulpcore's template.config.yml. This stanza should always (and only) contain:
      • The most-current (i.e., newly-released) branch.
      • All branches in use by supported downstream products (see below). These are branches we will consider backporting selected bugfixes to.
    • 7) Monitor pulpcore pull-requests for creation of a PR such as "Update supported versions". Such PRs are created by this job. The job may have been disabled if there hasn't been any release-activity in the repository for at least 60 days. You will need to re-enable it in this case. me possible failures of Step 2, above, include:
      • If release-tag is new but not based on current-dev, workflow will complain and fail
      • If release-tag is for an existing release (by accident) , the workflow won't fail until the docs-pub. Cleaning this up can be Exciting.