To Release or Not to Release: What's a Good Schedule

Shakespeare once said "A rose by any other name would smell as sweet". I wonder if something similar can be said for software releases.

I am planning a new release of the opensource Roundup Issue Tracker. Historically, release schedules were on an as needed basis. Before 2006 (when version 1.0.0 was released) there were multiple years with more than 10 releases (including alpha/beta and other pre releases).

But there were no releases from 2013 until 2016. Also, there was a gap in 2017. There was significant development done during those years without releases. But only those willing to run code from the repository were able to benefit. In 2018 I took over as release manager and chose to start doing yearly releases.

Why Release

With opensource projects, there are many reasons to release:

• get features/bug fixes to users
• thank contributors
• increase project visibility
• establish expectations
• provide deadlines

As I mentioned above, producing a release makes the work of contributors (developers, documentation writers, people reporting issues) isn't generally available. Frequent releases align with my preference to reduce WIP (work in progress). Thanking the contributors by releasing their work helps drive enthusiasm and engagement.

Announcements on multiple platforms accompany each release. When I see another issue tracking/bug reporting program release announcement, I experience FOMO over the marketing provided by their announcement.

A regular release cadence helps users to schedule time for testing or upgrading the software. Also, regularly scheduled releases encourage developers to finish their work and get it into a release. This deadline also drives me to go through all the steps to generate a beta and final release. This year (2023) will be my 6th yearly release.

When to Release

Although I do believe that reducing WIP is important, Roundup is not provided as a SAS (software as a service). It is deployed on-prem and meant to be customized. Some changes to Roundup require changes to a customized installation as part of the upgrade. For example:

• upgrade from Python 2 to Python 3 can require rewriting a tracker's business logic
• support for newer databases versions can require table alteration (sometimes manual, sometimes programmatic using the roundup-admin migrate command)
• security improvements and CSRF protection require changes to customized HTML templates.

I mentioned my FOMO when seeing other products release multiple times a year. I often see releases with 5 or so changes. Often these changes fix cosmetic issues or broken fields in the web interface.

With Roundup, many users have redesigned/replaced part of the interface. A release only supplies changes to the reference interfaces. The Roundup administrator needs to merge the reference changes into their production interface. In Roundup, changes can be implemented in production without requiring a release. This separation of concerns between the Roundup core and a customizable tracker makes Roundup more flexible. But, increases the work required during an upgrade.

Because of how customizable Roundup is, I try to balance between WIP and the churn caused by frequent releases. Yearly seems to be a sweet spot. There are occasions when a new core feature needs a change/bug fix. In that case the user has a choice to wait for a new release or use the most recent commit to the development repository.

If Roundup was a SAS with more limited customizability, we could do canary deploys directly from the repository. This would positively affect:

• getting features/bug fixes to users
• thank contributors

but would also reduce the utility of Roundup. Setting up a Getting Things Done tracker for his/her family would find it very difficult in a SAS based model. Also, the tempo of releases in a SAS based model may not align with the user's needs for a stable platform.

If Shakespeare were a software writer would he have penned "Would software by another release schedule smell as sweet?". Leave your thoughts in the comments.

(Cover Image by Glen Carrie)