3356
Comment: add steps for backports
|
4076
Rename plinth to freedombox where appropriate
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
This is a brief description of the process of releasing a new version of FreedomBox. | This is a brief description of the process of releasing a new version of !FreedomBox. |
Line 5: | Line 5: |
1. Check that [[https://salsa.debian.org/freedombox-team/plinth/pipelines|unit tests]] are not broken. 1. Run plinth [[https://salsa.debian.org/freedombox-team/plinth/blob/master/functional_tests/README.md|functional tests]] against current master. |
1. Check that [[https://salsa.debian.org/freedombox-team/freedombox/pipelines|unit tests]] are not broken. 1. Run freedombox [[https://salsa.debian.org/freedombox-team/freedombox/blob/master/HACKING.md#running-functional-tests|functional tests]] against current master. |
Line 12: | Line 12: |
1. First, check if there are any [[https://hosted.weblate.org/projects/freedombox/plinth/#repository|uncommitted changes]] on weblate. Commit if there are any. | 1. Check if there are any [[https://hosted.weblate.org/projects/freedombox/plinth/#repository|uncommitted changes]] on weblate. Commit if there are any. 1. Clone the freedombox repository, and check out latest master branch. |
Line 14: | Line 15: |
1. Update debian/changelog in the Plinth repository, including details that are relevant to contributors. * You can run {{{gbp dch -a --multimaint-merge}}}, then remove duplicates. * Also check [[https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=plinth|plinth bugs]] to see if any Debian bugs should be closed by the changes in the release. |
1. Run {{{gbp dch -a --multimaint-merge}}} to update debian/changelog. * Check [[https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=plinth|plinth bugs]] to see if any Debian bugs should be closed by the changes in the release. |
Line 18: | Line 18: |
1. Update the [[FreedomBox/ReleaseNotes|Release Notes]] on the wiki. This is a summary of changes that are relevant to end users. | 1. Update the [[FreedomBox/ReleaseNotes|Release Notes]] on the wiki. This is a summary of changes that are relevant to end users or otherwise important to note. |
Line 22: | Line 22: |
1. Commit these changes with the message "Release <version> to unstable". | 1. Commit these changes with the message "Release v<version> to unstable". |
Line 25: | Line 25: |
* Recommended to test by installing the package in a development environment, or by building a freedom-maker image with --custom-package. * You can also run autopkgtest: * {{{autopkgtest --apt-upgrade -B <new freedombox .deb> <source folder> -- lxc --sudo autopkgtest-unstable-amd64}}} |
1. Run autopkgtest: * {{{autopkgtest --apt-upgrade -B <new freedombox .deb> <source folder> -- qemu ~/autopkgtest/sid}}} 1. Test the new package by installing the package in a development environment, or by building a freedom-maker image with --custom-package. |
Line 32: | Line 32: |
1. After the release is accepted into Unstable, create a tag for the release. Push commits and the new tag to the Salsa repository. | 1. After the release is accepted into Unstable, create a (signed) tag for the release. Push commits and the new tag to the Salsa repository. |
Line 37: | Line 37: |
1. Publish changelog on various channels - [[https://discuss.freedombox.org/c/announcements|discussion forum]] mailing lists, irc and matrix groups, Twitter or GNU Social etc. | 1. Publish changes from Release Notes on various channels: * [[https://discuss.freedombox.org/c/announcements|discussion forum]] * mailing lists * irc and matrix groups * Mastodon or Twitter, etc. |
Line 49: | Line 53: |
1. Build the binary package with {{{gbp buildpackage -v<previous version>}}}. | 1. Build the binary package with {{{DIST=buster-backports gbp buildpackage -v<previous>}}} where <previous> is the previous version in backports. 1. There is a [[https://app.vagrantup.com/freedombox/boxes/freedombox-buster-dev|vagrant box]] based on buster that can be used for testing. * Set it up using [[https://salsa.debian.org/freedombox-team/freedombox/snippets/273|this Vagrantfile]]. 1. Run autopkgtest: * {{{autopkgtest --apt-upgrade -B <new freedombox .deb> <source folder> -- qemu ~/autopkgtest/buster}}} 1. Sign the dsc and changes files with debsign. 1. Upload the changes file with dput. 1. After the release is accepted into backports, create a (signed) tag for the release. Push debian/buster-backports and the new tag to the Salsa repository. |
This is a brief description of the process of releasing a new version of FreedomBox.
Pre release (work in progress)
Check that unit tests are not broken.
Run freedombox functional tests against current master.
- Check if boot process happens on one image.
Release
Releases are currently done every 2 weeks.
Check if there are any uncommitted changes on weblate. Commit if there are any.
- Clone the freedombox repository, and check out latest master branch.
Update translation strings by running python3 setup.py update_translations. Commit.
Run gbp dch -a --multimaint-merge to update debian/changelog.
Check plinth bugs to see if any Debian bugs should be closed by the changes in the release.
Remove any (Closes: nnnn) that refer to Salsa issues rather than Debian bugs.
Update the Release Notes on the wiki. This is a summary of changes that are relevant to end users or otherwise important to note.
Fetch the latest manual by running make -C doc fetch. Commit.
Update the version number in plinth/__init__.py.
Run dch -r and finalize the changelog.
Commit these changes with the message "Release v<version> to unstable".
Build the package using gbp buildpackage.
- Check for any new lintian errors.
- Run autopkgtest:
autopkgtest --apt-upgrade -B <new freedombox .deb> <source folder> -- qemu ~/autopkgtest/sid
- Test the new package by installing the package in a development environment, or by building a freedom-maker image with --custom-package.
Build the source-only package using gbp buildpackage --changes-option=-S.
- Sign the dsc and changes files with debsign.
- Upload the changes file with dput.
- When the release is accepted into Unstable, you will get an email "Accepted plinth x.y.z (source) into unstable".
- After the release is accepted into Unstable, create a (signed) tag for the release. Push commits and the new tag to the Salsa repository.
- Weblate will automatically update with the latest changes.
Post release (work in progress)
- Publish changes from Release Notes on various channels:
- mailing lists
- irc and matrix groups
- Mastodon or Twitter, etc.
- Upload new image to Vagrant Cloud.
Backports
A release can be backported to stable-backports after it has migrated to testing.
- Check out the debian/buster-backports branch.
- Merge the latest release tag.
- There will be a merge conflict due to debian/changelog. Resolve it by arranging the releases in the correct chronological order.
Run dch --bpo to add the debian/changelog entry for the new backport release.
Commit this change with message "Release <version> to buster-backports".
Build the binary package with DIST=buster-backports gbp buildpackage -v<previous> where <previous> is the previous version in backports.
There is a vagrant box based on buster that can be used for testing.
Set it up using this Vagrantfile.
- Run autopkgtest:
autopkgtest --apt-upgrade -B <new freedombox .deb> <source folder> -- qemu ~/autopkgtest/buster
- Sign the dsc and changes files with debsign.
- Upload the changes file with dput.
- After the release is accepted into backports, create a (signed) tag for the release. Push debian/buster-backports and the new tag to the Salsa repository.