This is a brief description of the process of releasing a new version of FreedomBox.
Pre release (work in progress)
Check for test failures in CI pipeline, which includes functional tests.
- 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 main branch.
Update translation strings by running make update-translations. Commit the changes in plinth/locale/.
- Exception: If uploading to experimental, then probably want to skip this, so that translators can continue working on the version in unstable and testing.
Run gbp dch to update debian/changelog.
Check freedombox 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 the changes in doc/.
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
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 freedombox yy.nn (source) into unstable".
After the release is accepted into Unstable, create a signed tag for the release using gbp tag. 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/bookworm-backports branch, and pull latest changes.
- Merge the release tag of the version in testing.
- There will be a merge conflict due to debian/changelog. Resolve it by arranging the releases in the correct chronological order, and then commit.
Run dch --bpo to add the debian/changelog entry for the new backport release.
Commit this change with message "Release <version> to bookworm-backports".
Build the binary package with DIST=bookworm-backports gbp buildpackage -v<previous> where <previous> is the previous version in backports.
- Run autopkgtest:
autopkgtest --apt-upgrade -B <new freedombox .deb> <source folder> -- qemu ~/autopkgtest/bookworm
There is a vagrant box based on bookworm that can be used for testing.
Set it up using this Vagrantfile.
Build the source-only package using DIST=bookworm-backports gbp buildpackage --changes-option=-S -v<previous>.
- 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 using gbp tag --ignore-branch. Push debian/bookworm-backports and the new tag to the Salsa repository.