pmaports-rtwo/.gitlab/issue_templates/Release_Infrastructure.md

Person in charge of the release (doesn't have to do all the work, but has to push it forward):

Preparation

• Create the gitlab milestone for the release
• Add this infrastructure issue to the milestone
• Update the timeline for the next release

Pre-Build phase

This phase is to get some extra time for building packages. The branch will be rebased once in the branch phase.

Requirements

• Alpine's main repository must be built and published
• Alpine's community repository must be built and published

pmbootstrap: adjust config

• Update pmb/config/__init__.py:apk_tools_min_version. This should be a trivial change, push it directly to main.
• (can be done later, at start of test phase) make a new pmbootstrap release bpo uses the main branch, so it will be fine without a release, however users will want to try out the new release and may not run main.

pmaports: create branch and initial changes

• git checkout -b vYY.MM main
• Create a === Branch vYY.MM from main === commit
  • Remove channels.cfg (should only be in main)
  • Change channel=edge to channel=vYY.MM in pmaports.cfg
  • Change supported_arches to x86_64,aarch64,armv7 in pmaports.cfg
  • Disable x86, armhf, riscv64 in .ci/build-jobs.yaml.j2 on the release branch and delete .ci/build-* scripts for these arches
• git push
• '''protect the new release branch in gitlab''', so nobody can force-push to it

pmaports: update main branch

• git checkout main
• Add the new branch to channels.cfg, like this
• git push

pmaports: update os-release / remove packages / aportgen

• git checkout vYY.MM
• Update postmarketos-base:
  • Set version info for /usr/lib/os-release in main/postmarketos-base/rootfs-usr-lib-os-release (PRETTY_NAME="postmarketOS vYY.MM", VERSION_ID="vYY.MM", VERSION="vYY.MM")
  • pmbootstrap pkgrel_bump postmarketos-base
  • pmbootstrap config mirrors.pmaports none
  • pmbootstrap config mirrors.systemd none
  • pmbootstrap checksum postmarketos-base
  • git commit
• Remove packages:
  • cross/*-armhf and other unsupported arches in cross dir (keep gcc-x86 and musl-dev-x86, systemd-boot-x86)
  • main/postmarketos-ui-asteroid (no smartwatches are useful on stable branches at the moment)
  • gcc4* and gcc6* from main and cross dirs
  • device/downstream, device/archived
• Run pmbootstrap aportgen for packages in cross
• git push

bpo: adjust config

• Add the branch to the build.postmarketos.org config in bpo/config/const/__init__.py:branches below branches["main"], so it builds with lower priority than main until it's released. Set ignore_errors to True.
• Make a merge request, wait until CI passes, merge it (or if you can directly push to main that's also fine since it's a trivial change)
• Roll it out/ask somebody who can do that
• Restart bpo, it will start building x86_64 packages

bootstrap of binary packages

• Fix failing x86_64 packages (Remember: patches need to go through edge first, then get backported to the stable branch!)
  • Try to get build fixes merged to edge quickly, ask for reviews in #postmarketos-devel, and consider merging trivial fixes right after they pass CI.
  • Devices in testing and archived categories that don't build: consider trying to fix them, or just delete them from the branch
• Wait until all packages for x86_64 are built and published
• Fix up ARM packages too
• Wait until all packages for ARM are built and published

Wallpaper poll

• Team meeting: make a short list of 4 wallpapers from the pool
• Make a poll on the wallpapers on mastodon (example)
  • Make sure to thank the wallpaper authors (usually dikasp) for the amazing work on the wallpapers
  • Put the names of the wallpapers on top of the wallpapers for easier voting and as alt text
  • Create a comment with poll options

Adjust CI

• Make sure pmaports.git CI runs through on the new branch (run pmbootstrap ci). Examples of why it might fail:
  • One postmarketos-ui package has a package from alpine testing in their _pmb_recommends.
    • Remove the UI if it is not used much (can bring it back on demand) or fork the package to the new branch
    • Consider fixing it in edge, so we don't run into this with the next release
• Adjust upstream-compat to run on the new release and make sure it passes (example)

Adjust release upgrade script

• Add the new release to upgrade.sh in postmarketos-release-upgrade
• Bump SCRIPT_VERSION, tag a new release
• Package it for edge (make MR), backport it to the new release, but NOT to the old release yet (otherwise users may upgrade by accident, without realizing that the new version is not out yet!)
• Adjust CI of postmarketos-release-upgrade to test the new release too (git grep for the previous release to see what needs to be adjusted)

Update the wallpaper

• Set the wallpaper that won in the poll in edge, backport this change to the stable release branch

Branch phase

Rebase on main

• git checkout vYY.MM
• git rebase -i origin/main
• Temporarily enable force-push for the vYY.MM branch
• git push --force-with-lease
• Disable force-push for the vYY.MM branch again

Update BPO config

• Update bpo's images config to build images for the new branch for all devices in community and main, except for:
  • qemu-*
• bpo: configure the new branch to be not WIP anymore
• Roll-out bpo changes

pmb release done?

• Ensure that a pmbootstrap release been made with the apk-tools min version change

Test phase

• Create an issue in pmaports with a checklist of devices and UIs in main and community (see previous issue for reference)
  • Tag the testers of each device and UI
  • Ask to verify that the images work as expected
  • Release upgrade script: when coming from the previous release, grab it from main: wget https://gitlab.postmarketos.org/postmarketOS/postmarketos-release-upgrade/-/raw/main/upgrade.sh
• Announce the new phase in the testing chat - and ask them to do the testing within one week, as in the timeline.
• Prioritize merging fixes from maintainers (they do the heavy lifting in the testing and fixing phase, see timetable)
• Make sure to properly cherry pick fixes from MRs to edge, if they are intended for the upcoming release
• Add new version to the pmaports gitlab issue template (.gitlab dir)

Release phase

• Did a reasonable amount of devices get tested? (we may consider dropping devices that were not tested)
• Make sure all fixes are in
• Make sure new images are generated with the fixes (unless it's a fix for something that doesn't impact the experience much and is fine to get with the first update after installing)
• Announce the new phase in the testing chat, together with the planned date of blog post release (and testing)

Write blog post

• Write a blog post for the new release in postmarketos.org.git:
  • Look at the previous release blog post and try to make the new one consistent with it
  • Highlight major changes since the last release (see the release notes issue)
  • Mention new devices, and total list of devices
    • Count devices that have their own wiki page as separate device
    • E.g. OnePlus 6, 6T are two devices (two wiki pages), but variants of "Samsung Galaxy A3 (2015)" are one device (one wiki page)
    • Don't count/list devices for which we don't build images (e.g. qemu-amd64)
  • Adjust the homepage config to point to the new release in the downloads page
    • update config/download.py:
      • latest_release
      • update devices and categories. only list the ones where we actually build images.
  • Add some cool photos
  • Submit the blog post as MR to postmarketos.org.git.
  • Let the blog post MR close the current release notes issue.
  • Ask for reviews.

Release!

• Backport the new postmarketos-release-upgrade version that allows upgrading to the new release, to the previous release (don't do this before the release is tested and ready! During the testing phase, we can use postmarketos-release-upgrade from main directly: wget https://gitlab.postmarketos.org/postmarketOS/postmarketos-release-upgrade/-/raw/main/upgrade.sh)
• Add the branch to pkgs.postmarketos.org
• Merge the blog post
• Edit channels.cfg, change descriptions:
  • New release: "Latest release / Recommended for best stability"
  • Old release: "Old release (supported until YYYY-MM-DD)" (one month from date of the release)
• Create a milestone for the next release
• Create an issue for the next release notes and attach it to that milestone
• Update the Releases page
  • Move the new release to the list of active releases, link to the blog post
  • Update the announcement and title for the release
  • Add a new upcoming release below
• Update Template:Latest stable release on the wiki with the new version
• Update "Default description template for issues" in pmaports (.gitlab dir)
  • In "On what postmarketOS version did you encounter the issue?", change:
    • previous release: add " (supported until YYYY-MM-DD)"
    • add the new release
• Put a reminder in recurring-admin-tasks to drop support for the old release