Release 0.18.0

[prestist]

Release checklist:

Tagging:

• Write release notes in docs/release-notes.md. Get them reviewed and merged
  • If the release signing key has changed because a new Fedora release has gone stable, note the change as done here.
  • If doing a branched release, also include a PR to merge the docs/release-notes.md changes into main
• Ensure your local copy is up to date with the upstream main branch ([email protected]:coreos/butane.git)
• Ensure your working directory is clean (git clean -fdx)
• Ensure you can sign commits and any yubikeys/smartcards are plugged in
• Run ./tag_release.sh <vX.Y.z> <git commit hash>
• Push that tag to GitHub

Fedora packaging:

• Update the spec file in Fedora:
  • Bump the Version
  • Switch the Release back to 1%{?dist}
  • Remove any patches obsoleted by the new release
  • Run go-mods-to-bundled-provides.py | sort while inside of the butane directory you ran ./tag_release from & copy output into spec file in # Main package provides section
  • Update changelog
• Run spectool -g -S butane.spec
• Run kinit [email protected]
• Run fedpkg new-sources $(spectool -S butane.spec | sed 's:.*/::')
• PR the changes in Fedora
• Once the PR merges to rawhide, merge rawhide into the other relevant branches (e.g. f37) then push those, for example:

  git checkout rawhide
  git pull --ff-only
  git checkout f37
  git merge --ff-only rawhide
  git push origin f37

• On each of those branches run fedpkg build including rawhide.
• Once the builds have finished, submit them to bodhi, filling in:
  • butane for Packages
  • Selecting the build(s) that just completed, except for the rawhide one (which gets submitted automatically)
  • Writing brief release notes like "New upstream release; see release notes at link to docs/release-notes.md on GH tag"
  • Leave Update name blank
  • Type, Severity and Suggestion can be left as unspecified unless it is a security release. In that case select security with the appropriate severity.
  • Stable karma and Unstable karma can be set to 2 and -1, respectively.

GitHub release:

• Wait until the Bodhi update shows "Signed ✔️" in the Metadata box.
• Verify that the signing script can fetch the release binaries by running ./signing-ticket.sh test <x.y.z-r> <output-dir>, where r is the Release of the Fedora package without the dist tag (probably 1)
• Run ./signing-ticket.sh ticket <x.y.z-r> and paste the output into a releng ticket.
• Wait for the ticket to be closed
• Download the artifacts and signatures
• Verify the signatures
• Find the new tag in the GitHub tag list and click the triple dots menu, and create a draft release for it.
• Upload all the release artifacts and their signatures. Copy and paste the release notes from docs/release-notes.md here as well.
• Publish the release

Quay release:

• Visit the Quay tags page and wait for a versioned tag to appear
• Click the gear next to the tag, select "Add New Tag", enter release, and confirm
• Visit the Quay tags page for the legacy coreos/fcct repo and wait for a versioned tag to appear
• Click the gear next to the tag, select "Add New Tag", enter release, and confirm

RHCOS packaging for the current RHCOS development release:

• Update the spec file
  • Bump the Version
  • Switch the Release back to 1%{?dist}
  • Remove any patches obsoleted by the new release
  • Run go-mods-to-bundled-provides.py | sort while inside of the butane directory you ran ./tag_release from & copy output into spec file in # Main package provides section
  • Update changelog
• Run spectool -g -S butane.spec
• Run kinit [email protected]
• Run rhpkg new-sources $(spectool -S butane.spec | sed 's:.*/::')
• PR the changes
• Get the PR reviewed and merge it
• Update your local repo and run rhpkg build
• File ticket similar to this one to sync the new version to mirror.openshift.com

CentOS Stream 9 packaging:

• Create a rebase-c9s-butane issue in the internal team-operations repo and follow the steps there

Housekeeping:

• Ask bgilbert to update the MacPorts package

[bgilbert]

This is still waiting on a few things.

[Okeanos]

Is there any chance at all that my PR (#289) can make it into this release?

[bgilbert]

Yes, that's the plan.

[bgilbert]

Remaining items:

• docs: add simple examples for SSH key & systemd file references (#179) #444
• docs: document command for generating GRUB password hashes #445

[bgilbert]

Actually, let's not hold for #444. If it gets in, great, but it's not super-important that it land in a release immediately. The docs website will update as soon as that PR lands in main.

[prestist]

https://pagure.io/releng/issue/11364