Open main menu

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

Creating a new release branch


Creating a new release branch, like vXX.YY:

  • git checkout -b vXX.YY master
  • Create a === Branch vXX.YY from master === commit (third line: Related:
    • Remove channels.cfg (should only be in master)
    • Change channel=edge to channel=stable-next in pmaports.cfg
    • replace master in .gitlab-ci.yml (example)
    • set pkgrel of all packages back to 0
  • git push
  • protect the new release branch in gitlab, so nobody can force-push to it
  • bpo
    • add the branch to bpo's config, for x86_64 only
    • push and restart bpo
  • 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)
  • run pmbootstrap aportgen for packages in cross
  • push pmaports changes, bpo should start building now.
  • bpo
    • wait until all packages for x86_64 are built and published, fix packages as necessary
    • after x86_64 is published, activate more arches (if you activate them before, the builds will fail due to missing cross compilers!)


Cherry-picking commits from master

  • In merge requests, that shall be cherry picked, add the cherry-pick-to-stable label. It is the responsibility of the person doing the merge, to also cherry pick it to the stable branch.
  • 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).