This post was last updated 2021-06-28T04:00:00Z to detail the current processes.
Hi everyone! Multiple topics to address here, let me see if I can cover them all.
This is an intentional decision on our end. We don’t have a formal release system for our beta releases. We put out a new release when it makes sense for us to do so. As such, there is generally little warning before a release, and thus not a lot of time to write up release notes. @codinghorror decided it did not make sense to hold up a release to wait for the notes to be ready.
Beta releases are now coordinated between the engineering and community teams. Release notes should be live at the same time as beta releases, if not shortly prior.
You will not see release notes for beta1. To avoid confusion, release notes are written for all beta releases. Stable releases will also receive notes. Do note, beta1 (of any version) is pretty much identical to the last beta from the previous release.
To understand why this is I’ll need to explain a bit about how our branches are configured.
For our purposes here we need to know about 4 branches of Discourse: main, tests-passed, beta, and stable.
Main:
When a new commit is added to Discourse it is on the main branch. Main is the absolute latest (most current) branch of Discourse, and we do not recommend anyone run their site tracking the main branch.
Tests-passed:
When a new commit is pushed the to the main branch, our build server automatically runs all our tests against the latest code. Once they all pass the commit is added to our tests-passed branch. This is the branch all Discourse sites run by default.
Beta:
Every few weeks we push the current commits on tests-passed to beta. We use beta as a “milestone” to push out a collection of commits we want more sites to be running and test. We also push a beta if we have an important security fix we want sites to receive. When a beta is pushed all sites running on tests-passed or beta receive the “new update available” email. Sites running tests-passed will update to the current tests-passed commits (including any new commits pushed after the beta), while those on beta will not.
Stable:
Every 4-6 months we release a new stable build. ~2 weeks before pushing stable we release our last beta. We then watch our logs closely to try and catch any lingering bugs that exist, and avoid adding any new features/risky changes. Once we’re satisfied with the state of the current beta, we push to stable.
Understanding the above, let’s use 2.0.0 as an example. We pushed 2.0.0.beta10 on May 16. All users running tests-passed or beta received an email (and we assume updated). I wrote release notes for that beta. ~2 weeks later on May 31 we pushed that build to stable as 2.1.0. To ensure users running on tests-passed or beta also receive the update, we pushed the same build out as 2.1.0.beta1.
Does this all make sense? Is there something I could do differently with the release-notes in #feature:announcements to make this clearer?