Create release branch
Jump to navigation
Jump to search
This is relevant for maintaining the repository only, regular users will not need this guide.
Contents
Creating a new release branch
Checklist
Creating a new release branch, like "v20.05":
git checkout -b v20.05 master
git push
- protect the new release branch in gitlab, so nobody can force-push to it
- remove channels.cfg (should only be in master)
- adjust channel in pmaports.cfg
- replace "master" in .gitlab-ci.yml (example)
- remove packages:
- device/testing
- cross/*-armhf, cross/*-x86
- run
pmbootstrap aportgen
for packages in cross - add the new branch to master's channels.cfg
- bpo
- add the branch to bpo's config, for x86_64 only
- 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!)
Maintenance
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 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
- 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).