Our Release Cycle

luceos

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.

luceos

luceos 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

Beta 10 took 2 months.
Beta 11 took 2 months.
Beta 12 took 3 months (one month extra for holidays planned).
Beta 13 took 2 months.
Beta 14 took 5 months (one month extra for refactoring planned).
Beta 15 took 2 months, 5 hours and 21 minutes.
Beta 16 took 2 months, 3 weeks, 2 days (one month extra planned for winter holidays)
v1.0 took 2 months, 1 week, 3 days

luceos

luceos 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.

Did anything change in this process since September 2019?

We moved to naming new iterations "Builds" to hint at the number of releases we tackled, no matter what version they are tagged with. This also reduces the need to think about naming branches etc.
We are still targeting (and increasingly succeeding) to release a new version every two months.
We no longer feature freeze, development can continue during the QA period. This period now takes a full week to take into consideration busy agendas.
We no longer freeze PR merging. Fixes to issues found by QA are merged, anything else is either postponed to after the upcoming release or is merged into a new temporary branch named after the next build.
Instead of using nightly.flarum.site (and having to cope with outside user interaction), QA now has its own testing website at https://qa.flarum.site. We no longer deploy to discuss before a release because honestly it is using far too many community and premium extensions which aren't often patched for the nightly version yet. We often prioritize patching extensions used on discuss by ~~pressuring~~ sweet talking the maintainers into updating while giving direct assistance from the core team.
We still have one global kanban style project board. It no longer holds all issues but only those for the upcoming release. During the whole development cycle it holds issues from public repositories (flarum/core right now); at the end of a cycle it contains our release checklist issue.
We no longer have a release coordinator, although as project manager I guess that responsibility now falls onto me.
Releases are now handled by two people, where in the past primarily one person would tackle our whole release checklist (which is vast mind you). Tasks that can be handled ahead of the release, like changelogs, are now a shared effort of the team.
As to monthly meetings, we have reduced that to just the Kick off meeting. Activity on internal Discord channels has exploded since though and the opportunity to go one-on-one for a quick chat or peer coding session seems to have become more accessible.

The fact that we're still going strong with a process similar to the ones we adopted over a year ago, is just awesome. We still have a long way to go to optimize how we do things, but we are in no rush to take small steps to get to the best result.

luceos

luceos Beta 10 took 2 months.
Beta 11 took 2 months.
Beta 12 took 3 months (one month extra for holidays planned).
Beta 13 took 2 months.
Beta 14 took 5 months (one month extra for refactoring planned).
Beta 15 took 2 months, 5 hours and 21 minutes.
Beta 16 took 2 months, 3 weeks, 2 days (one month extra planned for winter holidays)
v1.0 took 2 months, 1 week, 3 days

In terms of accountability:

v1.1 took 4 months, 2 weeks
v1.2 took 2 months, 1 week, 1 day
v1.3 took 3 months, 3 weeks
v1.4 took 2 months

So what has changed?

We moved to one central roadmap board to track generic progress for 1.x and 2.0: https://github.com/orgs/flarum/projects/22/views/1
Although failing to release each two months, I have high hopes that we can regain that cycle moving forward. Especially now that we're compensating some of our developers for their work on Flarum.
We still do deployments of nightly to discuss at times, living on the edge helps put some pressure on the kettle 😉
We moved all repositories into one mono repo (see https://www.perforce.com/blog/vcs/what-monorepo for some explanation)

Darkle

luceos Great to see the huge improvement since the first post (I hadn't seen this discussion before), out of curiosity, how is the switch to monorepo going? Do you feel it's making things easier/more efficient?

luceos

Darkle I certainly believe collaboration, but also contributions have improved. There are still some open tasks that need to be resolved (php tests should run as one testsuite), but overall I think it was a very good decision.

SychO

Darkle as a core developer, 100%. Not having to switch context between multiple repositories is a huge time saver. It was a bit difficult to get some things right and some things we're still figuring out, but overall, good decision imo.