Design decision 9 - Release early, release often (STR)

Summary

Issue

We already know it, having time-based releases is good practice, and having releases quarterly too, however it can lead to multiple issues down the road. At the moment, the challenges we are encountering with such release cycle are the following:

Other widespread issues worth mentioning with the approach of having longer delays between releases are:

Proposed solution

Keep the regular quarterly release process as is since it is needed, and on top of that have on-demand releases conditionnally to whether changes made during that time frame affected the WET API as described in Design decision 3 or not, and if there is a demand for a new release. Frequent releases could occur as often as weekly or bi-weekly.

An interesting analogy describes well the intent of such proposal: Walking up a staircase is easier than scaling a sheer cliff of the same height, meaning it is easier to manage frequent small releases than long big releases.

Background

The concept of releasing early and often rose from a shifting in development practices over the last decades. Waterfall lost its popularity to agile and consequently to that time between deploys had to reduce.

Implications

A frequent release cycle can consume a good chunk of time writing release notes, so it would become necessary to put in place a simplified release process, including having release notes based mostly on contributions and what has changed. Pages like the changelog and roadmap will be discountinued to lighten the overall process.

Notation

Proposed notation would be to have a Short-term release (STR) tag tied to every frequent releases, in order to well identify them and knowing that even though they are considered stable releases, probabilities of them having more bugs than quarterly releases are higher and that a newer release is just around the corner.

Research