Releasing Weblate#
Releasing schedule#
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.
Ver también
Release planning#
The features for upcoming releases are collected using GitHub milestones, you can see our roadmap at <https://github.com/WeblateOrg/weblate/milestones>.
Release process#
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 -j 12 -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.yml
to cover it in migration testing.Increase version in the website download links.
Increase version in the repository by ./scripts/set-version.
Check that readthedocs.org did build all translations of the documentation using ./scripts/rtd-projects.
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 hub tool and access to create releases on the Weblate repo
SSH access to Weblate download server (the Website downloads are copied there)