Is Discourse always in "beta"?

You can’t swap to stable until it catches up. Discourse doesn’t support downgrades.

A better question is: why would you want to?

Stable isn’t as widely used, the focus for development is on tests-passed.

Assuming you aren’t blindly upgrading a production site, and are testing each upgrade prior to deployment, the most feature-rich and well supported release is going to be the default.


Sorry, this must be somekind language barrier matter-issue, but does the focus mean

  • development of Discourse itself and how branches are build
  • everybody else is doing mostly development of Discourse

First one means that production sites that have focus on functional and stable forum should use test-passed.

Second one means a production site, that products forum, not coding, should use stable.

Yes. I desperate need some english lessons because these nuances aren’t totally clear for me.

But when the first guess is right, why there is stable-branch if it is not ment to be used?


We run tests-passed in production on our hosting. It’s 100% meant for production sites.

Stable means all the software bugs are known. You won’t be getting anything new (including new bugs, but also bug fixes) until the next stable version is released. It’s simply site preference – want features as they come? Use tests-passed. Want an absolutely stable build that won’t change except in major version updates? Use stable.


To that I’d add “want to wait 6 to 8 months for something that is a bug but not deemed a security risk to be fixed?” Use stable.


That’s not entirely true. There are many bugfixes backported to stable.


Well, that’s quite true I’m sure.

But hypebole is the best thing ever!


True, the showstopper ones. Smaller bugs are not.


It would be good if there were a choice in the general instructions, sort of like LibreOffice download choices or Debian.

I am hosting the site on DO but my co-owner was originally from as a subdomain, and he sees all of this maintenance and say “Why don’t we just use discourse hosting?”

I told him that we have our own name, server, higher tier plugins (like emoji likes and google sign in), and other things. I told him that he was probably using older discourse and never updated either.

I too would rather just use stable and forget about it until 6 months later. I’m a daily driver of Ubuntu, but I get a little nervous typing in those few build commands. Plus the server goes down for 5 minutes when I rebuild.

On the other hand, I’m going to request a backup feature to be integrated and would jump on beta for it :rofl:

Just to avoid any kind of speculation: at Communiteq (formerly you get your own hostname, plugins of your choice on the Professional plan and up, and we backup and update your forum for you. So yes, most of your problems will indeed be solved by using managed hosting.


The original issue was to request provide a stable build option in the github install instructions. I see that you provide stable releases for your customers. Perhaps you can kindly explain how to clone and install a stable release? That was also my original question.

As a small and semi-private group, there is no justification for anything less than the DO $5 server. However, you have a great service for $40 per month for the professional plan or the basic plan. I wish you the best of luck. It is a good deal compared to the official discourse plans. All options are great for those who can afford this. That is the great part of FOSS.

1 Like

I believed the decision to install on tests-passed by default is quite intentional.

It’s far easier to support new installations at a single software level. As the support provided here is community-based and for the most part 100% free there’s no good reason to complicate it.


The standard install instructions are simplified for a reason.
Running stable is considered an advanced setup, so you need to edit the app.yml by hand. You can search for “version” and see documented there what to do.

Modifying discourse-setup to include this as an option would be confusing to most people, so I don’t think it’ll be added there.


Maybe a helpful metaphor is that the “stable” branch is like the disc based Microsoft Office, whereas the “tests-passed” branch is like the cloud based Office 365. Both are viable options, and both get updates eventually, but for a product that’s fundamentally online already and which has a small support team, it’s more productive to be able to instruct people to update their installations to the current code, so that bugs can be tested and fixed promptly. As a forum admin it’s great to be able to report a bug and update to a version that fixes it within a few days, sometimes even the next day. I haven’t used any other web apps that are as responsive as that. (Not that every bug is fixed instantly, but many are.)


@pfaffman, I followed the link and the one it led to, but saw nothing about setting the config to stable. What am I missing? Do you mean 'search the app.yml file for “version” '?

but I don’t think you can go from test-passed to stable (as you would go back in commit and probably need to reverse some migrations in the database, unless your test-passed version is old enough to be over-passed by the newest stable I suppose :thinking:)


Thanks for the speedy reply!

I was expecting that the updating would just suspend until the next stable release cycle.

Any insight on this? Why would anything immediately change from flipping the #version switch?

1 Like

A general warning about using stable @mlgtechuser: if you use or plan to use third party plugins and/or theme components many of them don’t support stable and they are usually maintained against tests-passed. This may not be an issue now and may depend on how your usage evolves …


third party plugins and/or theme components many of them don’t support stable and they are usually maintained against tests-passed .

So what you’re saying is that beta versions could be better tested and more stable than stable?
I don’t want so sound rude, but who came up with this, honestly?

The replies in this topic have been summarized in a single post as a proper explanation: Why does Discourse always install "beta" versions by default? :slight_smile: