-
Notifications
You must be signed in to change notification settings - Fork 41
Release Plan [draft]
See also: Continuous Delivery; Kanban Agile
The first releases of Freeciv21 were very ad-hoc and not well defined. They were mostly to fix important bugs or just when we felt like working on something. This worked well for a while, until a game was no longer being played and the flow of new bug reports winded down. Then we switched to goal-based releases (using the milestone feature of Github). We started selecting issues and published a release once all of them (or at least a vast majority) were closed. This worked quite well for the first release because we picked mostly bug fixes. For the second goal-based release, we included features into the mix and it took a long time to get it out. This is happening again for the beta2 release.
The Freeciv21 development community is going with a hybrid approach to releases. The rationale is now that we have more than one developer and a much more active community, we need to release updates more often. As of this writing, we are currently working on the Beta.4 milestone and Beta.3 has been released.
At this step the team determines what the next milestone (goal) will entail. Github issues are associated with the milestone and the milestone is given a version number. More than one future milestone can be classified to show a bit of a future road map, however that is not required. It is recommended that as a current milestone gets close to 90% complete, the next (future) one is drafted and discussed among the team.
At this step we release every 7 days. Here is how that works.
For sake of example. Assume the current released version is 3.0-beta.3 and the next milestone is 3.0-beta.4. The Beta.4 milestone has 50 or so issues associated with it and one week has passed since the milestone was established and completed. Around 50 or so commits have been made to the master branch since the release of Beta.3.
The Release Manager drafts a point release using the releases feature of github (the same one we use for all the other releases). He/She captures all the pull requests that have gone into master as normal and gives the tag a point release version one up from the prior one.
Using our example, this means that the next point release is 3.0-beta.3.1 and every week after is 3.2, 3.3, 3.4 and so on until all the issues tagged to the Beta.4 milestone are complete and is released as a full release based on the goal set.
I think we need to distinguish between features and bugs in the planning. Features can easily be much larger than initially planned and delay a release significantly. Bugs, on the other hand, tend to take less time. We should also be careful that while new features often introduce new bugs, the reverse is usually not true. Thus I think we need some kind of feature freeze.
Feature freezes are problematic because they block new development. They are also frustrating for contributors if their shiny new feature is delayed by two years. So the freeze needs to be as short as possible and also take into account how bug-prone a feature is. So I'm thinking about something like this:
| Weeks | What can go in | Notes |
|---|---|---|
| 1-2 | Everything | Unstable part of development (but bug fixes are of course welcome). |
| 3-5 | Everything "stable" | This includes features that are subjectively considered moderately risky (because they are small, easy to test, only affect specific rulesets, ...). |
| 6-7 | Only fixes and tweaks | Stabilization period. |
| 7 | Prerelease short turn | We pick a ruleset that makes us use the new features of the release and play a short turn game. Planned well in advance so as many people as possible can join. Aim for 2-3h of play on a weekend. |
| 8 | Only fixes | Fix anything discovered in the test game. |
This planning enforces a release every 2 months (doesn't mean delays are impossible if some bug fixes take too long). Some releases will be bigger, some will be smaller, but they will always include fixes to the dependencies in the Windows and Mac packages. Documentation is only subject to these rules when it comes to infrastructure changes. Rulesets and art also live their own life.
With this calendar, a breaking feature approved on week 3 would take 14 weeks (3.5 months) before seeing a release. I think it is acceptable and there are good chances that the developer would still be around to fix any issue discovered in their code. For smaller features the maximum duration is 3 months. Bug fixes take at most two months to come. The average durations are 10 and 8 weeks for larger and smaller features, respectively.
If we go for such a plan we need some changes to the infrastructure:
- New tags to classify PRs (so we can ignore ones not for the current merge window). For instance
pr:big-change,pr:small-change, ``,pr:bugfix - Automation and instructions for releases (make it as easy as possible)
- Automation to inform about the merge windows? For instance when we mark a PR as
pr:big-change, a message sayingThis pull request was classified as "big". The next window for it is from XX-YY-ZZZZ to XX-YY-ZZZZ. - Automation to perform the merges? Like merging all pending & approved
pr:big-changeimmediately after the release