Release cadence

[matt0x6F]

Hello all! I've started thinking about a more regular release process. Here's my proposal:

Athens will track two release types:

1. Hygiene release which will serve to update dependencies and fix
2. Feature releases which will introduce net new features

Hygiene releases

These will incur a patch version bump. Example: 0.13.1 => 0.13.2. Features which change existing behavior should not be included in these releases.

Feature releases

These will incur a minor version bump. Example: 0.13.3 => 0.14.0. Features and fixes will go into these releases.

Context

What makes this challenging is that Athens is released directly from main. We don't have LTS', we don't have curated branch releases, etc. It is entirely possible that a feature may have to get released off-cycle in order to solve a CVE.

Generally, I feel this is an acceptable risk because we balance the safety of releases and merges with very thorough testing of contracts. We're sensitive about not breaking core aspects of Athens for our customers.

FAQ

What about Major releases?

One day, Athens will need a refactor and code clean up. That day will incur a Major release. Major releases should also result in a clean up of our issue board and other project management artifacts.

[atkinsonm]

Following the semver model:

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

fits your definition of hygiene releases, and

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API.

fits your definition of feature releases. It can be hard to decouple them when tagging main. Your options boil down to:

1. Release often, maybe every PR, and gate PRs into main on having a clear release queue
2. Bundle multiple features and hygiene changes together and release less often.
3. Adopt gitflow-style release branches for release candidates, and only merge released code into main.

[matt0x6F]

Thanks for this!

Could 1 be colloquially referred to as rolling releases? Although I like the idea of releasing on a schedule, maybe releasing more often with less changes per release is what's best for the project.

2 or 3 is what I'd like to do, but I feel like we don't have enough staff to do that kind of release model.

[matt0x6F]

We've internally committed to a hygiene release once a month (on the 15th) and feature releases will occur on the 1st of the month if there are features to be released. This gives us the latitude to test changes and puts us on a predictable rhythm.

[atkinsonm]

Is it fair to say that PR merging will be gated on that schedule?

[matt0x6F]

Not necessarily. PRs will get merged, but the tagged release and subsequent artifact releases will be done on the first and fifteenth. So, say you complete a bug fix on the seventh the release it'll go out on will be on the 15th.

Oh, I also was probably a little clumsy with that wording. A feature release will just be another hygiene release if there aren't features to go with it.