Our release management follows one rule: it’s ready when it’s ready, and when it’s ready we ship it.
Simple enough have me as the main maintainer for Hanami until now.
With the new people joining the team, and perhaps new collaborators, we want to coordinate the effort between us.
What worked so far…
The current model worked fine because in a pre-1.0 era, you’re in a discover phase, and it’s hard to predict when the building blocks of a framework are ready.
However, the lack of time-boxing had a few downsides.
Contributors who promised to deliver a feature, after they opened the draft PR, they disappeared. Large components never get right at the first cycle, they need to be polished, documented, tested in real projects. Opening a PR and leaving it, it’s like never working on it in the first place. Again, I believe that the lack of a date for the release may have removed the sane pressure to actually finalise features.
The other problem that we faced is to not give in developers’ hands a preview of a major feature. Releasing a feature after right it has been merged it’s not good for the stability a release.
What we can do? I think we should introduce a few basic rules:
Still follow Semantic Versioning 2.0
For a feature we should have an owner and a backup: in case the owner can’t finish it, the backup can take over the leadership. The two people must communicate over time. As soon one of them cannot continue to work on the feature, they must communicate to the core team.
Agree on a date when the feature should be ready to be merged. That implies that the PR should be opened largely in advance (a month is ideal). So we can have time to iterate, polish, document.
We won’t to jump straight to a stable release, but go through the alpha/beta/rc (aka pre-release) cycle.
After we merged one or more features, we should be able to craft a pre-release, so developers can try it and report bugs.
New APIs must be tagged with the YARD annotation:
We should be able to release a patch version for bug and security fixes anytime.
masterwill become the branch that is always ready to be shipped for bug/security fixes. New features must use
developbranch as target for PRs.
We should decide one of the following release models:
It’s ready when it’s ready
We can keep this current model of release by adopting the rules described above.
We should evaluate from release to release the coordination between features and how to put them in developer’s hands as soon as we can.
Fixed Release Cycle
Before a stable release is out we decide which features to implement for the next cycle. For instance, before 1.0, we should decide what goes in 1.1 and who’s gonna be responsible for each feature.
Starting from the stable release, we target the next stable release to happen 6 months later.
The first 4 months are to develop the new features, while the remaining 2 months are for the pre-release cycle.
If a feature takes less time, the person can decide to take another feature.
If a feature takes more time, we should still merge it, but make it not part of the public api (hence the
This 6 months cycle is for new features, bug/security fixes should be released as soon as we can. These small releases must be patch releases. Eg.
That means each 6 months we will bump a minor or major version: it could be
1.2… or we can decide to go for
This model has the implicit advantages of the time constraint and the coordination between features.
Please suggest improvements.