clarify when releases happen
add link for plinth CI
|Deletions are marked like this.||Additions are marked like this.|
|Line 5:||Line 5:|
|1. Check that unit tests are not broken.||1. Check that [[https://salsa.debian.org/freedombox-team/plinth/pipelines|unit tests]] are not broken.|
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.
Releases are currently done every 2 weeks.
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.
Also check plinth bugs to see if any Debian bugs should be closed by the changes in the release.
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.