With the 2.19.0 release, I changed how ZoiteChat releases were going to be managed.
The idea was to keep patch releases focused on fixes while doing new feature work on
master for the next minor release.
The reasoning behind that still makes sense, but after actually working with the new process for a while, I have found that parts of it created more overhead than they solved.
What was not working
Maintaining a separate release/2.19 branch while also continuing work toward
2.20.0 on master effectively meant maintaining two active versions of ZoiteChat.
Fixes needed to be kept in sync between both branches, while new features continued separately
on master.
The bigger issue is that even a small ZoiteChat patch release still involves most of the same release work as a larger release. Testing, builds, packaging, release notes, publishing, and the other release steps do not become much smaller just because the release contains only one or two fixes.
In practice, this meant more branch management and more releases, while also making it harder to keep normal development moving.
What is changing
Going forward, master will once again be the main active development branch.
Bug fixes, maintenance work, and new features will normally be developed there and included in the next regular release.
Patch releases will still exist, but they will be used when there is a good reason to make one, such as:
- a serious regression;
- a security issue;
- a significant crash or usability problem;
- a packaging or installation problem;
- or another issue that should not reasonably wait for the next regular release.
Smaller fixes will normally remain on master and ship with the next minor release.
Versioning is not changing
This does not mean going back to putting features into patch releases.
- Patch releases, such as 2.19.1, will remain focused on fixes and maintenance.
- Minor releases, such as 2.20.0, can include fixes along with new backward-compatible features and improvements.
- Major releases will continue to be reserved for larger compatibility changes.
The main difference is that every bug fix will no longer automatically mean maintaining and releasing another version from the previous stable branch.
Smaller minor releases are fine
I am also changing how I look at minor releases.
A release like 2.20.0 does not need to contain a huge list of new features. If master
has a useful improvement, some fixes, and is in a good state to release, that is enough.
This should provide a better middle ground between the old process, where too much could end up inside a patch release, and the newer process, which created too much ongoing release and branch management.
Going forward
Most development will now happen in one place: master.
Stable patch releases can still be made when they are actually needed, but maintaining a separate active branch for every release series will no longer be the normal workflow.
The goal is still to keep ZoiteChat releases predictable and avoid unnecessary regressions, while also keeping the development process practical enough that work can keep moving forward.