Design decision 9 - Release early, release often (STR)
- Expert: @GormFrank
- Status: Approved and published
- Type: Refine current practice
- Last updated: 2020-01-23
- (2020-01-23) Published
- (2020-01-15) Approved at the WET roadmap meeting
- (2019-12-18) Presented the update at the WET roadmap meeting
- (2019-12-02) Updated to reflect first attempt
- (2019-10-23) Presented at the WET roadmap meeting
- (2019-10-23) Initial draft
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:
- Canada.ca GCWeb version is out of sync with the actual project.
- We are always working on a dev-tagged version of WET and GCWeb right after a release is made all the way to the next one.
- Wait time for some new features or upgrades can seem lengthy for implementors.
Other widespread issues worth mentioning with the approach of having longer delays between releases are:
- Bugs can get carried until next release.
- The longer you wait to make a release, the greater the compromise on quality is made as you are getting closer to that release.
- Refusal from implementors to upgrade their code to a newer version if a release bundles too many changes.
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.
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.
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.
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.