clarify process of releasing package
update changelog / release notes steps
|Deletions are marked like this.||Additions are marked like this.|
|Line 9:||Line 9:|
| 1. Update the [[https://github.com/freedombox/Plinth/blob/master/CHANGELOG.md|Changelog]] in the Plinth repository, and the [[FreedomBox/ReleaseNotes|Release Notes]] on the wiki.
* The Release Notes are a summary of changes relevant to end users.
* The Changelog includes more details that are relevant to contributors.
| 1. Update debian/changelog in the Plinth repository, including details that are relevant to contributors.
1. Update the [[FreedomBox/ReleaseNotes|Release Notes]] on the wiki. This is a summary of changes that are relevant to end users.
This is a brief description of the process of releasing a new version of FreedomBox.
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.
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. Push master and the new tag.
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.