Scheduled releases are a fundamental part of the Tiki model. As a large community, it makes it clear for everyone what to expect. There are two major releases per year (October and April), with several minor releases in between. Please see: Roadmap and Version lifecycle.
Now, that is for the “big picture” schedule. The exact date of these releases is flexible and often is shifted a few weeks to coincide with a TikiFest. And even then, the Release can delay this according to his/her best judgment.
A crucial role of the release coordinator is to decide when to branch and when to release.
During the release cycle, people work extra hard to add/fix things. That extra energy is only there because the release is imminent. Even though we have a release schedule, the release manager has some flexibility.
- On one hand
- There can be some legitimate blockers that make the release manager judge that a release in the current state would cause more pain than good (ex.: installer broken, data corruption, etc.)
- Even without blockers, it’s hard to stop people when they are doing all this awesome work. We want more popcorn.
- OTOH, if we wait too long, and the release cycle drags on too long, we’ll burn out our resources. A lot of burnt popcorn is not good.
Thus, the art of the release manager includes knowing when the time comes for the real release after all the alphas, betas and release candidates. To have the maximum amount of popcorn, without burning out the team.