v22.12 Infrastructure

Timeline and template: https://wiki.postmarketos.org/wiki/Create_release_branch

Preparation

• Discuss who's in charge of the release (doesn't necessarily mean doing all the work, it can be delegated. just someone to keep pushing it forward)
  • me, @ollieparanoid
• Create gitlab milestone for the release -> https://gitlab.com/groups/postmarketOS/-/milestones/14
• Create an issue in pmaports named "vYY.MM Infrastructure", add it to the milestone, copy paste the checkboxes from this list
• Assign the person who's in charge of the release to the infrastructure issue
• Update the timeline for the next release
• Post it in the release party channel

Branch phase

pmbootstrap: adjust config

• add apk-tools min version
  • https://pkgs.alpinelinux.org/packages?name=apk-tools&branch=edge
  • pmb/config/__init__.py:apk_tools_min_version
• should be a trivial 1 line change, push it to master directly
• (can be done later, at start of test phase) make a new pmbootstrap release bpo uses the master branch, so it will be fine without a release, however users will want to try out the new release and may not run master.

pmaports: create branch and initial changes

• git checkout -b vXX.YY master
• Create a === Branch vXX.YY from master === commit (third line: Related: https://wiki.postmarketos.org/wiki/Create_release_branch)
  • Remove channels.cfg (should only be in master)
  • Change channel=edge to channel=vXX.YY in pmaports.cfg
  • Change supported_arches to x86_64,aarch64,armv7 in pmaports.cfg
  • replace master in .gitlab-ci.yml (example)
• git push
• '''protect the new release branch in gitlab''', so nobody can force-push to it

pmaports: update master branch

• git checkout master
• add the new branch to channels.cfg, like this
• git push

pmaports: update os-release / remove packages / aportgen

• git checkout vXX.YY
• set version info for /etc/os-release in main/postmarketos-base/rootfs-etc-os-release, bump pkgrel, update checksum, commit
• remove packages:
  • device/testing, device/unmaintained
  • cross/-armhf, cross/-x86
  • main/postmarketos-ui-asteroid (no smartwatches are useful on stable branches at the moment)
  • main/postmarketos-ui-framebufferphone until aports#13857 is resolved
• run pmbootstrap aportgen for packages in cross
  • may not be necessary if the branch was just created, since the packages on edge and the new stable branch will be the same
• git push

bpo: adjust config

• add the branch to the build.postmarketos.org config
  • bpo/config/const/__init__.py:branches
  • for x86_64 only
  • ignore_errors: True
  • add it below branches["master"], so it builds with lower priority than master until it's released
• 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.
• wait until all packages for x86_64 are built and published
• after x86_64 is published, activate armv7, aarch64 arches in bpo (if you activate them before, the builds will fail due to missing cross compilers!)
• fix up ARM packages too
• wait until all packages for ARM are built and published

Images: config & issue

• update bpo's images config to build images for the new branch for all devices in community and main, except for:
  • qemu-*

Adjust CI

• disable x86, armhf in .gitlab-ci.yml on the release branch
• make sure pmaports.git CI runs through on the new branch. 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 monitoring 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 and to the old release
• 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)

No more WIP

• bpo: configure the new branch to be not WIP anymore
• 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
  • Tag the maintainers of each device and UI
  • Ask them to verify that the images work as expected
  • => #1815 (closed)
• Announce the new phase in the release party 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

Release phase

• Did everybody test their devices? If not, we need to drop them.
• 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 release party chat, together with the planned date of blog post release (and release party)

Write blog post

• look at previous release blog posts for inspiration, then prepare a MR with the following changes.
  • update config/download.py in postmarketos.org.git:
    • latest_release(_title)
    • update devices and categories. only list the ones where we actually build images.
• write a blog post for the new release:
  • Highlight major changes since the last release
  • 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)
  • Explain upgrade path (previously: Upgrade release, maybe just update that wiki page and link to it again)
  • Adjust the homepage config to point to the new release in the downloads page
  • Add some cool photos: header image by Caleb, thanks!
  • Submit the blog post as MR to postmarketos.org.git. Make sure the team sees it.
  • Wait for reviews

Release!

• 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)
• Update the Releases wiki page
  • Move the new release to the list of active releases, link to the blog post
  • Add a supported until date for the old release (but keep in the "active" list for now)
• Update "Default description template for issues" in pmaports
  • https://gitlab.postmarketos.org/postmarketos/pmaports/edit
  • 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 your calendar to drop support for the old release in one month (see below)
  • create a new issue with dropping the old release (template)
• Ping Martijn to add the branch to pkgs.postmarketos.org config
• Do the conference call in jitsi and celebrate the release :)