The documentation for Plume.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

2.3 KiB

title icon summary
Release process truck What we do between each releases


Plume follows semantic versionning. The 0.x series is for alpha versions. The x doesn't actually correspond to the alpha number, because 0.1.0 was before the first release, and 0.2.0 was the first alpha. This has been fixed with the fourth alpha, which is the 0.4.0 version, by skipping the third alpha.

Beta versions or pre-release uses the -rcX suffix, where X is the number of the release canditate.

Major version changes when API or federation has a breaking change (they should in the same release as much as possible), not when major changes are made to the interface for example (even if the two are often linked).

What gets in each version

We don't set deadlines for new releases. We just assign issues (either bug to be fixed or feature requests) on Gitea to a given milestone as we feel it, and once it is complete, we make a new release.

→ Milestones list on Gitea

We should prefer making small releases often, than big ones once a year or so.

The release itself

When we decide to make a new release, we give two weeks to translators to update translations. During this period bug fixes and new features are accepted, as long as they don't change the messages used in the interface.

At the beginning of the string freeze, the new version of the .pot files are uploaded to Crowdin, with all the new messages that were added during the cycle.

At the end of these two weeks, the updated .po get pulled in the main code repository.

We should make sure the documentation is up-to-date before publishing a release. The dev branch of the docs should be merged into stable to be deployed on

For each release, we make an announcement as a blog post (on Plume of course), a message on the Matrix room, and a more technical/impersonal changelog on the Gitea release page (basically a list of the PR that were merged since the last release). This last technical changelog should include any steps that should be taken for this specific update that are not listed in the general update documentation.