Difference between revisions of "Creating a release branch"

From postmarketOS
Jump to navigation Jump to search
Line 29: Line 29:
 
* push pmaports changes, bpo should start building now.
 
* push pmaports changes, bpo should start building now.
 
* bpo
 
* bpo
** add the branch to bpo's config, for x86_64 only (make a merge request and ask MartijnBraam/ollieparanoid to review and roll it out (push, restart bpo))
+
** add the branch to bpo's config, for x86_64 only (make a merge request, wait until CI passes, merge it and roll it out/ask somebody who can do that)
 
*** https://gitlab.com/postmarketOS/build.postmarketos.org
 
*** https://gitlab.com/postmarketOS/build.postmarketos.org
 
*** <code>bpo/config/const/__init__.py:branches</code>
 
*** <code>bpo/config/const/__init__.py:branches</code>

Revision as of 06:52, 18 June 2021

This is relevant for maintaining the repository only, regular users will not need this guide.

Creating a new release branch

Checklist

Creating a new release branch, like vXX.YY:

  • Wait until Alpine creates their 3.14-stable branch in aports.git (or whatever the next release is based on).
    • Alpine's workflow is setting up new builders and build edge from scratch first, and only after that is done, the new branch gets created. (postmarketOS workflow is the other way around, we create the branch first, then build all packages from there.)
    • There is no fixed timeline from when the builders start up to when the branch gets created, typically a few weeks.
    • The builder status can be followed at build.alpinelinux.org
  • 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
    • replace master in .gitlab-ci.yml (example)
  • git push
  • protect the new release branch in gitlab, so nobody can force-push to it
  • remove packages:
    • device/testing, device/unmaintained
    • cross/*-armhf, cross/*-x86
    • cross/gcc4*, main/gcc4, cross/gcc6*, main/gcc6
    • main/postmarketos-ui-asteroid (no smartwatches are useful on stable branches at the moment)
  • add the new branch to master's channels.cfg (like this, but note that we don't have stable, stable-next etc. anymore)
  • add apk-tools min version to pmbootstrap
  • 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
  • push pmaports changes, bpo should start building now.
  • bpo
    • add the branch to bpo's config, for x86_64 only (make a merge request, wait until CI passes, merge it and roll it out/ask somebody who can do that)
    • wait until all packages for x86_64 are built and published, fix packages as necessary
      • Patches need to go through edge first, then get backported to the stable branch!
      • Try to build fixes merged to edge quickly, ask for reviews in #postmarketos-devel, and consider merging trivial fixes right after they pass CI.
    • 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 packages too
    • after all packages are built, update bpo's images config to build images for the new branch for all devices in community and main
    • create an issue in pmaports with a checklist of devices in main and community, tag the maintainers of each device, and ask them to verify that the images work as expected

Maintenance

Cherry-picking commits from master

  • In merge requests, that shall be cherry picked, add the backport-to-vXX.YY label.
  • If the new release is not finished, backport the patch to the branch right after merging.
  • If the new release is finished, add it to the service pack branch and issue (see creating a service pack)
  • It would be best if the person that merged the patch did the backport, but the author of the patch should double-check and do it in case it wasn't done, just to be sure.
  • Use git cherry-pick -x ffffffff (insert commit to cherry pick accordingly). The -x will add a (cherry picked from commit ffffffff) line to the commit message.
  • Cherry picked commits shall not be squashed, then it's hard to understand which commits were already picked and which were not.
  • If git reports conflicts, resolve them.
    • If you have cherry-picked a commit, that has touched a lot of devices that don't exist in the stable branch, then you can use git rm $(git status | grep "deleted by us" | cut -d ':' -f 2).
    • Look at the git diff to make sure that the result is as expected.
  • If it's something non-trivial, then make a merge request for the cherry-picked commits so we see that it was done correctly, it builds and that we may test the packages before merging.
  • Avoid cherry-picking multiple patches that touch the same pmaports in the wrong order (related comment).