When I get that “New Discourse version, update available” email from my forum (this time about 2.1.0.beta1), I know @jomaxro 's elaborate release notes will appear here within 6-24 hrs. or so. It’s not very important, but I would organize it in a different order.
I agree, first thing I do is go and look at the release notes to determine whether or not I am going to apply the update.
There is a high level release note list here: Discourse Version 2.1
The notes are in the above topic, so this is covered.
I’m not seeing any notes specifically for 2.1b1. Just a general list of goals for the final version of 2.1.
I’m off today (family event), will respond to this properly next week. Short version: there are no major changes from the last release notes (2.0.0.beta10) and 2.1.0.beta1 - we simply pushed 2.0 to stable and moved work to 2.1.
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.
You will not see release notes for beta1. 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:
When a new commit is added to Discourse it is on the master branch. Master is the absolute latest (most current) branch of Discourse, and we do not recommend anyone run their site tracking the master branch.
When a new commit is pushed the to the master 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.
Every few weeks we push the current commits on
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
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.
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
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
beta also receive the update, we pushed the same build out as