v24.06 Infrastructure
Timeline and template: https://wiki.postmarketos.org/wiki/Create_release_branch
Preparation
- Discuss who's in charge of the release -> @ollieparanoid
- Create gitlab milestone for the release
- 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
Special for v24.06
Previously we have only built devices from the main and community categories for the stable releases. I'm curious if it is feasible to build some of the 464 (!) devices we have in testing for the stable release as well... if so, it would make these much more useful. In the sense of: grab a random android device, check if it is at least in postmarketOS testing, and then get a stable postmarketOS / alpine on it and use it e.g. as server in your lan / in a VPN where you don't have high security requirements (as obviously the random downstream kernels are not very secure).
So for this release, I plan to:
- branch v24.06 early from master, do related tasks of the branching phase early
- attempt to build all packages on it, ignoring failed testing devices (I expect a lot of them to fail since we don't build them very often)
- in the branching phase (CW 22): branch current v24.06 again from master, keeping the already built binary packages on v24.06
If too many devices fail to build or building all of these takes so long that we wouldn't have time to do the rest, then I'll just remove the testing devices again as usually.
=> it worked! we now have 211 devices from testing (and even 6 from archived) 
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=edgetochannel=vXX.YYin pmaports.cfg -
Change
supported_archestox86_64,aarch64,armv7in pmaports.cfg - disable x86, armhf, riscv64 in .gitlab-ci.yml 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 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 (possibly skip this time, see note above)
-
cross/*-armhfand other unsupported arches in cross dir (keep gcc-x86 and musl-dev-x86, they are needed for systemd-boot for x86_64) - main/postmarketos-ui-asteroid (no smartwatches are useful on stable branches at the moment)
- main/postmarketos-ui-framebufferphone until aports#13857 is resolved
- gcc4* and gcc6* from main and cross
-
run
pmbootstrap aportgenfor packages in cross -
git push
bpo: adjust config
-
add the branch to the build.postmarketos.org config
-
bpo/config/const/__init__.py:branches - ignore_errors: True
-
add it below
branches["master"], so it builds with lower priority than master until it's released
-
- make a merge request, wait until CI passes, merge it (or if you can directly push to master 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.
- 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
-
make sure pmaports.git CI runs through on the new branch.- CI code has been refactored, doesn't run for each push anymore. It should work, if it doesn't then we fix it when errors show up.
-
adjust monitoring to run on the new release and make sure it passes (example) -- fails because of https://gitlab.com/postmarketOS/monitoring/-/issues/8 currently
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)
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 -> #2861 (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 (.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 release party chat, together with the planned date of blog post release (and release party) (Skipped)
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
- update devices and categories. only list the ones where we actually build images.
-
update config/download.py in postmarketos.org.git:
-
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
- Submit the blog post as MR to postmarketos.org.git. Make sure the team sees it.
- Wait for reviews
Release!
- Backport the new postmarketos-release-upgrade version that allows upgrading to the new release, to the previous release
- 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)
-
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 (.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
-
In "On what postmarketOS version did you encounter the issue?", change:
-
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) -> #2891 (closed)
- Do the conference call in jitsi and celebrate the release :) (skipped, too late today
