Releasing new versions of Flarum in a timely manner has been one of the hardships we, as a team, have been facing for years. The releases started to gradually span apart as the team battled to get to stable.
- beta 2 took 1 month
- beta 3 (with 4) took 1.5 months
- beta 5 took 5 months
- beta 6 took 7 months
- beta 7 took almost 9 months
- beta 8 took 1 year and 5 months
- beta 9 took 7 months
Feeling the pain of our users, the community and embracing the excitement people have for stable, it was time for change.
Inspired by GitLab and Agile methodologies, we found our solution in a fixed release cycle. No matter the tasks in this release, we target a specific release date. Even though we initially decided to hold off until a stable release, with our recent boost in motivation we decided to go for it now and use beta 10 as our testing grounds.
A few of the principles that we relied on:
- Target the release on a specific date in two months.
- Feature freeze (issues) one week before release.
- Freeze pull request merging three days before release.
- Allow QA and discuss-powered testing during the feature freeze phase. We use nightly.flarum.site, deploy latest changes to discuss and test locally.
- Work Kanban style using one GitHub organisation wide board for the release with the columns Backlog, To Do, In Progress, Review and Done.
- Appoint and rely on the Release Coordinator to keep us aware of our deadlines. For someone adopting a badly scoped position @Ralkage has been doing an awesome job.
- Hold a team meeting every month, in sync with the cycle, so that we can discuss technical and organisational topics regularly and keep our heads pointed in the same direction.
We're still shaping our processes where needed, but I'm already extremely happy with the results we've managed to achieve and I hope you do too too, now that we released beta 10.