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:
Branch off from a commit -- either from the main branch, or from an already existing release branch
(Optional) Cherry-pick commits from other branches, or develop fixes/features as needed
Update changelogs in the main branch and in the new branch
Update the Cargo.toml and Cargo.lock files in the new branch
Make sure tests pass
Tag the Cargo update commit with the release version
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!
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 theCargo.toml
andCargo.lock
files. As the1.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:
Cargo.toml
andCargo.lock
files in the new branchIdeally, 2, 3 and 4 would be bundled in a PR, which would ensure 5 gets verified.
Pros:
Cons:
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!