Stable Release Channel

I am running discourse inside of a docker container a pretty standard deployment.

I love the fact that I can do upgrades from the web browser, but I’m wondering if there is a way to subscribe to ‘stable’ releases instead of getting upgrade notification for:

2.5.0.beta7

Maybe wait till the beta releases are done and let me upgrade to 2.5.1 once it’s released?

4 Likes

You can edit your app.yml file to point to the stable branch (stable). The line you want to edit is version, it defaults to version: tests-passed.

Keep in mind that this means you’re waiting for months to update, which also means you’ll have to live with any bugs in that version for a longer time.

4 Likes

Note that you can only switch from beta / tests-passed to stable once a new major stable version (i.e. 2.5.0) is released. Going from tests-passed to stable right now would be a downgrade, which is unsupported.

5 Likes

If something was critical wouldn’t you back port the fix? I would expect if it’s something critical would happen it would be fixed. Or is that not the case?

I also have had more than a few bugs being introduced with the beta channel. So I suppose my assumption is that when you cut a new release you’ve done some sanity check to make sure that everything looks good and works as expected before moving on to 2.5.1

@RGJ, Thanks for the info noted. I’ll pin it down once the next Discourse version comes out.

1 Like

Security fixes are generally backported, yes. Critical (like, show stopping, unable to use Discourse) bugs are backported too. But many less critical bugs may not be. Backporting itself comes with risk, unintentional regressions can always occur, it forces users on stable to update, etc.

Our general recommendation is that sites follow the tests-passed branch (as is default), and update when a new release (beta) is out. There are certain cases where stable may be recommended, for example a site with complex plugins that override core templates, but for a standard, docker install site, stick with tests-passed. While the term “beta” in the software industry tends to make people think “there will be bugs”, that isn’t our intended use. All releases of Discourse, tests-passed, beta, stable, etc. have bugs.

If you find a bug on tests-passed and report it, chances are good will fix it within a few days and you can update to make the bug go away. You may encounter more (as in unique) bugs, but they’ll be fixed quickly. On stable, as Kris mentioned, you shouldn’t see any new bugs over the 4-6 month release, but any bugs you do have won’t go away until the next stable release. You’re likely to have more bugs at any given time than on tests-passed, since they’re not being patched, but the bugs should be constant.

9 Likes

The majority of sites appear to be running tests-passed and for good reason, the team are actively developing the product and it’s where they can be most responsive.

If you’re hitting problems I would be inclined to review your release processes over falling back to Stable.

An integration or staging copy will let you proactively test updates before rolling them out to your live environment, without leaving you weeks or months behind the curve.

4 Likes

Where popular Pavilion plugins (TLP, CW, QnA, Events, Follow, Ratings, Locations etc) are concerned, we currently track tests-passed and largely because of it being the default install as this is less confusing to users in general. This makes them incompatible with Stable most of the time currently, largely down to the velocity of development in Discourse core which evolves impressively fast.

We will keep this under review in case resources allow us to support additional branches or Discourse starts shipping the default install on another branch. So, for the time being, if you intend to use our plugins, please stick to tests-passed.

3 Likes