The Major Release Process

Why we have major releases?

Knowing “why” helps understand why we need a checklist here. We are constantly deploying customers and days after a major release we will often move ahead and deploy beta to customers in an endless cycle. So what is the point of having a major release?

  • We love to celebrate all the awesome changes we made. A release is a great excuse to

    • Give ourselves a nice pat on back for all the amazing work we did

    • Have a retrospective look at the last 6 or so months since the last release

    • Tell the world about the new release in a celebratory blog post

  • Following a cycle where we slow down for a bit for a few weeks and clean up helps maintain a stable product over time

  • Some crazy very risk averse non-customers like running “stable” versions of Discourse.

So… what is the process?

4 weeks prior to release

  • We aim to be done on all major feature work, if anything major is still being worked on resources we will re-allocate resources to make it happen or push to next release

  • Most of the team will be focused on “other” work, being

    • Never ending customer work like imports and FTEE work

    • Operations and improving our infrastructure.

  • @sam and/or @codinghorror will look through the bug category on dev and ensure that stuff needs to be in the release is farmed out

  • Entire team should be aware of the release target date and process.

  • :black_square_button: a closing the release topic shall be created

3 weeks prior to release

  • We should be done now with all major feature work by the end of the week

  • All site should be deployed to ensure what we release has been out there for a while, using the usual staggered update process.

  • A log party will be started, where devs will all spend extra time looking at errors at https://dev.discourse.org/logs and porting fixes into our code base.

  • A build stabilization party will start if we accrued debt and have an unstable builds

  • Much of the team will be focused on “other” work

  • A performance review will be done using mini profiler and possibly flame graphs to ensure there are no new perf regression and if there are any easy wins

  • :black_square_button: A log party topic shall be created

2 weeks prior to release

  • Very similar to previous weeks, except that priority on “log party” ramps up

  • Avoid creating new translation strings to give people more time

  • Attempt to avoid adding new strings

Release week checklist

  • Do not add new strings unless 100% needed

  • Everyone should be reviewing all checkins

  • Every change you make must be justifiable with “we NEEDED this change for release” or “there is no way this would impact release” (eg a spec refactor)

  • :black_square_button: a few “instance-in-the-cloud” upgrades via web UI to ensure that nothing broke.

  • Very low intensity work and follow https://dev.discourse.org/t/things-we-should-do-just-before-every-release/1673 till the release