Publication de Weblate

Release cycle

Weblate uses calendar versioning with monthly releases. The version format is <YEAR>.<MONTH>.<PATCH> with a numeric, non-zero-padded month. The <PATCH> part is omitted for the first release in a month when it would be 0, for example 2026.5. Patch releases use the full version number, for example 2026.5.1.

Monthly releases are usually published at the beginning of the month. Patch releases include bug fixes, security fixes, and dependency updates which should not wait for the next monthly release.

Direct upgrades are supported from releases in the current or previous calendar year. The first release in a new year drops direct upgrade support for releases from the year before the previous year.

The Docker container includes an additional version component to track changes in the container itself, such as dependencies. Fixed Docker image tags include the patch component together with this build component, even when the Weblate version omits a 0 patch component. These updates may include security updates.

Voir aussi

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

Choses à vérifier avant publication :

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

  2. Définir la version finale à l’aide de ./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

When building distribution packages locally, start from a clean checkout or remove ignored packaging artifacts such as build/, dist/, weblate.egg-info/, and generated weblate/locale/**/*.mo files.

Effectuer la publication :

  1. Créer une version ./scripts/create-release --tag (voir ci-dessous pour les exigences).

Étapes manuelles après publication :

  1. Fermer le jalon GitHub.

  2. Une fois l’image Docker testée, ajouter un libellé, puis pousser la nouvelle version.

  3. Inclure la nouvelle version dans .github/workflows/migrations.yml pour la couvrir dans les tests de migration.

  4. Incrémenter le numéro de version dans le dépôt à l’aide de ./scripts/set-version.py.

  5. Check that readthedocs.org did build all translations of the documentation using ./scripts/rtd-projects.py.

Pour créer des libellés à l’aide du script ./scripts/create-release, vous avez besoin de éléments suivants :

  • Accès pour pousser sur le dépôt Git Weblate (pour pousser les balises)