Stable release process

[ajanon]

There is currently no formal process for releasing a stable version of swhkd.

For 1.2.2, I created a separate branch, split from a specific older commit, on which I updated the Cargo.toml and Cargo.lock files. As the 1.2.2 version is a patch release (semver), this made sense to not include larger changes, such as new features.

This way of doing releases could be extended to all new swhkd releases.

Process proposal:

1. Branch off from a commit -- either from the main branch, or from an already existing release branch
2. (Optional) Cherry-pick commits from other branches, or develop fixes/features as needed
3. Update changelogs in the main branch and in the new branch
4. Update the Cargo.toml and Cargo.lock files in the new branch
5. Make sure tests pass
6. Tag the Cargo update commit with the release version
7. Create a release on GitHub

Ideally, 2, 3 and 4 would be bundled in a PR, which would ensure 5 gets verified.

Pros:

• Easy to cherry-pick fixes, security patches, and other updates onto the stable release branches
• Less version bumps commits on the main branch
• Clear history showing where releases diverge from the main branch
• Probably simpler to package, which may increase adoption (especially for non-rolling distros such as Debian, Ubuntu, Suse, etc)

Cons:

• This implicitly assumes that we support older releases, which may increase maintenance in the long run
  • This would in turn means we need to discuss how long we should support these older releases
  • And also, what would "support" actually mean for us?
• (too) many branches for each stable release, which will clutter the GitHub UI (personally, I think it is fine development-wise to have many branches)
• Divergence from the main branch

If we go forward with this process (or another), it could be documented either directly inside the repository (PROCESSES.md?) or the GitHub wiki.

As always, this proposal is debatable, feel free to chip in!