Versionning
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.
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 docs.joinplu.me.
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.