Discourse does not ship an LTS release

I was not aware of discourse-compatability, so that’s something I’ll need to read up on.

I’d like to address this, because it sounds like there is a huge disconnect between how the Discourse team thinks of stable and how the rest of the discourse community/larger forum admins community thinks of Discourse’s stable offering.

Key reasons why stable does not meet the definition of LTS.

1) Stable is actively dissuaded against by staff whenever it is brought up

I don’t necessarily want to call out individual posters, but here’s a selection of staff posts to show the theme:

Note that in some ways tests-passed is more stable than stable as it’s what discourse.org runs, so it’s the best tested.

So Discourse is in a perpetual beta state, meaning that we’re always working on new features and refinement. In our case beta does not mean unstable; we host sites with millions of monthly pageviews on our tests-passed and beta versions.

The stable channel is not necessarily more “stable” than tests-passed. It’s more about the idea that the bugs are known, and it serves as a checkpoint for a specific set of features and improvements. With tests-passed, there may be new bugs introduced, then fixed a few commits later.

The messaging has been pretty consistently that Discourse is in ‘perpetual beta,’ which is not the experience production / non dev users want to have.

In a quick duckduckgo search of the top ten links for discourse stable, none of them really seem to advocate in favor of using stable. So regardless of its actual quality, if staff are universally guiding people away from stable, it has a negative impression in people’s minds of being fit-for-purpose.

Stable might be great, but if we’re told over and over again it’s best not to use it, we’re not going to consider it for serious deployment.

2. An LTS receives bug fixes beyond just security bug fixes

An LTS is something that isn’t receiving feature upgrades, but does receive bug fixes. Per staff’s own comments, in Discourse there doesn’t seem to be effort put into backporting bug fixes for non-security issues. Maybe this is not true, but this is what we have been told.

3. An LTS has straightforward install steps

The install guide doesn’t even mention the existence of stable.

4. An LTS is widely used

Before your post, I hadn’t heard of any widespread usage of stable branch. Is it also being used widely in the wild? Given how hidden it is, I doubt it, but I don’t have any metrics to say. This is an important factor because it gives people confidence to use stable for their production deployments.

5. An LTS has clear release cycle & upgrade notes

I don’t see any central location where stable is being clearly documented. (I may just be missing it!)

My expectations for an LTS is a page which describes:

  • Current active release version
  • Release notes including:
    • Major changes/features between LTS versions
    • Migration steps from past LTS release (especially breaking changes to be aware of)
  • Planned active support length for each version

ex: mediawiki, but really any major open source LTS has similar pages.

This documentation helps me being able to plan around when there’s a breaking change that will require downtime and/or manual intervention.

6. An LTS has no major breaking changes within one release cycle

This may well be the case for stable, but I’m just too used to hitting the upgrade button and the forum going down to know for sure. I guess what I’m looking for here is more clear warning when going between versions that break something.

7. An LTS provides API deprecation warnings for at least one full LTS release cycle

These should be measured in the pace of a year+, as opposed to a month+.

8. An LTS is slotted / has overlapping support periods

Any large LTS will have an overlapping period of support between two LTS versions. Stable seems to just do a binary flip to the next version. (My impression may also be in error from there not being a central documentation page)

9. It is straightforward to upgrade from non-LTS to LTS

There’s no need to support going backwards, but when an LTS is available, it’s not clear how to cleanly switch branches over to LTS. It looks like there is some posts in the forum about it, but again, no centralized documentation that I could find.


I am a fan of Discourse, but this is a common pain point both I encounter and many other people encounter. What stable is right now is only branch, not an LTS.

1 Like

Moved this to its own topic, seems unrelated to bundling of plugins.

2 Likes