Weblate has two month release cycle for releases (x.y). These are usually followed by a bunch of bugfix releases to fix issues which slip into them (x.y.z).
The change in the major version indicates that the upgrade process can not skip this version - you always have to upgrade to x.0 before upgrading to higher x.y releases.
../admin/upgrade
The features for upcoming releases are collected using GitHub milestones, you can see our roadmap at <https://github.com/WeblateOrg/weblate/milestones>.
Things to check prior to release:
- Check newly translated languages by
./scripts/list-translated-languages. - Set final version by
./scripts/prepare-release. - Make sure screenshots are up to date
make -C docs update-screenshots. - Merge any possibly pending translations
wlc push; git remote update; git merge origin/weblate
Perform the release:
- Create a release
./scripts/create-release --tag(see below for requirements).
Post release manual steps:
- Update Docker image.
- Close GitHub milestone.
- Once the Docker image is tested, add a tag and push it.
- Update Helm chart to new version.
- Include new version in
.github/workflows/migrations.ymlto cover it in migration testing. - Increase version in the website download links.
- Increase version in the repository by
./scripts/set-version.
To create tags using the ./scripts/create-release script you will need following:
- GnuPG with private key used to sign the release
- Push access to Weblate git repositories (it pushes tags)
- Configured
hubtool and access to create releases on the Weblate repo - SSH access to Weblate download server (the Website downloads are copied there)