What goes in a release schedule?

In chapter 8 of Program Management for Open Source Projects, I include many suggestions for tasks and milestones that go into a project’s release schedule. But those suggestions are only examples, not a full and authoritative list. I sometimes see projects try to put a lot of extra stuff into the release schedule. After all, when you have a schedule hammer, everything looks like a milestone nail.

The first question to ask is “does this task impact the timing of the release or depend on the timing of the release?” You can’t ship a release that you haven’t built, for example. And you probably don’t want to publish an announcement before the release ships. Both of those tasks are clearly tied to the release and should be included on the schedule.

The next consideration is “does this task interfere with important release tasks?” For example, the Fedora elections could happen on a fixed calendar date. The important thing is that they happen, not when they happen. But if the elections were to be in full swing around the time of the release, it would be a big distraction. So it makes sense to tie the start of the elections to the release date to avoid that trouble. Similarly, the regular checks for inactive package maintainers could be done at any time, but they were chosen to be at minimally-intrusive points in the release cycle.

If the answer to both questions is “no”, then you probably want a regular calendar instead of the release schedule. “Gardening”-type tasks — issue tracker cleanup, wiki verification, and so on — are typically a good fit for a calendar. This is where you should track tasks that are low-impact (in terms of distraction, not outcome) and apt to be forgotten if not done on a regular cadence.

This post’s featured photo by Towfiqu barbhuiya on Unsplash