Release cycle

[markmandel]

As we head closer to what I think will be a 0.2 release - we should consider how we are doing releases going forward, and document that process.

In my mind there are two potential release cadences (although if there are more that people thing are appropriate, please feel free to put them forward).

1. We plan a set of priorities for each release, as we get close to completion of those priorities, the committers (and community) decide if we are ready for a release, slip anything we feel is worth slipping to the next release - go into feature freeze for a period (to be determined), only merge bug fixes and documentation PRs etc, and then release.
2. We have a regular cadence. For example, we will release every 2 months with whatever is in master. The last two weeks of the 2 month period we go into feature freeze and only accept bug fixes, and documentation submissions etc for that time. Then every priority issue (in that release's milestone) that isn't ready for that release rolls into the next release (the time periods I've outlined here are just arbitrary examples, we could do whatever). The only exception to this would be if there are critical bugs in the current release that would push a release out, or hotfixes/security issues that would need to come out post a release on an as-needed basis.

I think that while we are in alpha, I don't think we need to worry about doing release candidate builds/pre-release builds - as essentially everything is pre-release - but also happy to hear other opinions if people feel strongly otherwise (maybe we should still cut an rc to make user testing easier?). Once we hit a 1.0, I feel that this release cycle would change, but we can discuss that then.

I lean more towards option (2) because then users and contributors are always aware of what is coming, and when it is coming by and can plan appropriately, but would love to hear thoughts on either of these approaches (or other ones if you think they will fit) - each has pros and cons. If we can choose a general approach, then we can look at narrowing down the specifics on that process.

[markmandel]

Research

• https://about.gitlab.com/2015/12/17/gitlab-release-process/
• https://gravitational.com/blog/kubernetes-release-cycle/
• https://link.springer.com/chapter/10.1007/978-3-319-57735-7_16
• https://fnords.wordpress.com/2011/07/01/time-based-good-for-community/
• https://scalare.org/wp-content/uploads/2015/06/2015-Why-and-HowShould-OpenSource-ProjectsAdopt-Time-Based-Releases.pdf

This all seems to promote a time based release cycle.

[mcnjr]

I'm going to do some more reading and research but I like the idea of option 2 as it seems to lend itself more towards a CI/CD mindset that could be good to adapt early. I think as the project matures a bit more and there's less low hanging fruit the first option might be the better approach. I'd also be happy to help write documentation for whichever cadence we choose!

[cyriltovena]

I'm also in favour of option 2 mostly because it's more predictable like you said.

[markmandel]

So been doing some more reading, and this is what I'm suggesting (at least at broad strokes there are some finer details we can work out through the details of the pull request to write the documentation, etc).

Initial Release

• Do a 1 week RC, once Fleets are good to go (with whatever else is in master), and then go into feature freeze during that time - and release 0.2 at the end of that week.

Release cadence

• 6 week release cycle
  • 5 week development cycle
  • Releases on Tuesdays (in case hotfixes need to happen, we have the rest of the week)
  • Release a {baseversion}.RC (release candidate) release from whatever is in master.
  • 1 week feature freeze - so only bug and document fixes are merged during the week
  • then {baseversion} release is made
  • {baseversion} is incremented by 1 (i.e. 0.2 -> .0.3)
• Each release (rc and full) will have a release ticket made for it, which will have a checklist (which will have a documented template - to be developed during PR), including things such as:
  • setting git tags & branches
  • creating images and assets etc
  • creating the release in github
  • Creating a CHANGELOG.md

Doing some research I read/talked about everything from 1week -> 1 month -> 3 month release cycles - Going by gut feel, and how often we have PR's being merged, ~ a 5 week development cycle felt like a decent baseline for getting several new features for each release in, while also giving us enough breathing room to do the feature development.

Thoughts?

[mcnjr]

I like it! One thought: will there be an assigned release manager that is in charge of the checklist per release?

[markmandel]

@mcnjr I just assumed it would be me 😄 - at least for the first few rounds, and then we can always delegate/rotate.

In an ideal world, I'd like to make releasing as automated as I can. It should be a 20 minute job.