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).
| Year | Releases | Year | Releases |
|---|---|---|---|
| 2022 | 2 | 2009 | 5 |
| 2021 | 2 | 2008 | 5 |
| 2020 | 2 | 2007 | 3 |
| 2019 | 2 | 2006 | 13 |
| 2018 | 1 | 2005 | 8 |
| 2016 | 1 | 2004 | 19 |
| 2013 | 1 | 2003 | 16 |
| 2012 | 2 | 2002 | 12 |
| 2011 | 3 | 2001 | 7 |
| 2010 | 5 |
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: