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 plinth functional tests against current master.
- Check if boot process happens on one image.
Plinth Release
After deciding (with other developers) that a new release is needed:
First, check if there are any uncommitted changes on weblate. Commit if there are any.
Update translation strings by running python3 setup.py update_translations. Commit and push to master.
- Weblate will automatically update with the latest changes.
- 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.
Update the Release Notes on the wiki. This is a summary of changes that are relevant to end users.
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 and tag the release.
Build the package using gbp buildpackage.
- Check for any new lintian errors.
- Recommended to test 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.
- If upload is accepted into Unstable, be sure to push any commits and the new tag to the git repository.
Post release (work in progress)
- Publish changelog on various channels - mailing lists, irc and matrix groups, Twitter or GNU Social etc.
- Upload new image to Vagrant Cloud.