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.

See also

Upgrading Weblate

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:

  1. Check newly translated languages by ./scripts/list-translated-languages.

  2. Set final version by ./scripts/prepare-release.

  3. Make sure screenshots are up to date make -j 12 -C docs update-screenshots.

  4. Merge any possibly pending translations wlc push; git remote update; git merge origin/weblate

Perform the release:

  1. Create a release ./scripts/create-release --tag (see below for requirements).

Post release manual steps:

  1. Update Docker image.

  2. Close GitHub milestone.

  3. Once the Docker image is tested, add a tag and push it.

  4. Update Helm chart to new version.

  5. Include new version in .github/workflows/migrations.yml to cover it in migration testing.

  6. Increase version in the website download links.

  7. Increase version in the repository by ./scripts/set-version.

  8. 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)