Creating a release branch

From postmarketOS
(Redirected from Create release branch)
Jump to navigation Jump to search

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
  • 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).