Release Strategy: alternate between feature release and stability release

[jankapunkt]

Currently, we have released, based on what was most demanding and incorporated code quality and tests along with it.
However, features can grow faster than code quality aligns.

I therefore propose the following alternation:

1 - Feature release

• new features

• extending existing features

• perceivable UI/UX changes

• maybe backwards-breaking, but only if really necessary and justifiable + accepted by the team

• new features have to be tested and documented

• regressions need to be documented (better: avoided)

• three staged releases: alpha. beta, public release candidate

2 - Stability release

• code refactoring and code quality
• fixing bugs and uncovered regressions
• no extension or features
• UI/UX changes only, if correlating to bug fixes!
• no breaking
• improve test coverage, test automation and ci
• improved documentation (dev docs; user docs; deployment docs) where necessary

Why not incorporate stability in feature releases?

Well, this is already a goal of a feature release. It should contain appropriate tests, documentation etc.
However, new features brings new user feedback with new issues that we may not have thought about. Changing, fixing and updating these alongside new features will create tensions in our code.

Having a dedicated release for refactoring and fixes brings us other advantages:

• taking a step back and look at the code from an entire quality / maintenance / long term perspective
• prepare code for future changes/features (SOLID, patterns etc.)
• free mental resources that otherwise get used for creating / designing new things
• better focus on reviews: feature review and code quality reviews are separate processes

[kadewe]

Yes, let's do this "Tick-Tock-Release"-Strategy, Tock being the feature release and Tick the stability release. 🤩 Kinda Leopard-Snow Leopard release of macOS, Snow Leopard being one of the best macOS Versions ever released (high hopes for macOS Golden Gate…)