Discourse does not ship an LTS release

General
1

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.

3 Likes
2

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

3 Likes
3

If we consider the sad face in admin dashboard vs being so many commits behind in “Update discourse”

is the critical update part of tests-passed and if you “Update All” promptly after happy face to sad face, you will be in sync with tests-passed ?

4

I think this specific update requires rebuilding from the console. Twice.

1 Like
5

Discourse seems to have fairly high velocity in terms of change and an ambitious roadmap.

To support that it needs a lot of user feedback. I think there is a clear implicit strategy to promote tests-passed because that supports early feedback on new changes.

In return the user gets free software and new features. It’s a kind of pact. I think over time this deal seems to have been proven successful.

Stable build doesn’t really help development as much so it may not be in the business interest to promote it as much (just my opinion, I don’t speak for CDCK at all).

The other issue with stable is this, and it’s even more significant:

There are usually a lot of changes between stable versions, including significant deprecations and API changes. Involvement in tests-passed as a developer, site admin or theme creator gives you a chance to tackle changes in small bite-sized pieces, instead of having a huge mountain to climb each time you hit the next stable milestone.

To support those big jumps you are going to probably need a staging site and a bunch of tests cases to walk through.

If you don’t own any customisations yourself, you might go for stable, but you are relying heavily on others over whom you may not have any strong influence to ensure that any addons you are using are sufficiently maintained for your next upgrade. You may find that some elements lose support by the time it comes to upgrade and at that point you might find yourself in a bind. You may also find the developer doesn’t support stable at all and you may have to fork and prepare a “cut” of the plugin to support your stable build. (however, there’s a good pinning system in place so it’s not a huge amount of work)

The other piece of significance in Discourse is its very unit test intensive so the test-passed branch is usually very good from a stability perspective.

4 Likes
6

Given management’s refusal to undo unpopular changes like the plugin bundling, I don’t think this part is accurate. Maybe from a QA perspective, but even then I’ve had several kinda gnarly bugs not get fixed in past. At the end of the day, I realize they’re the ones investing time & money into it, so they get to make their decisions, but IMO I don’t think it’s a strategy to get more feedback.

I think the more realistic reason they do not support a proper LTS is it would cost someone on the team time managing/documenting it though. It’s a feature that primarily benefits self-hosters, so I imagine it would be considered a timesink to them. But it is kind of an expected feature and not having it is a real downside when forum admins choose their forum software since other contemporaries have more stable offerings.

7

On the contrary I think the plugin bundling is precisely to promote their use and as a result procure more feedback.

8

Management specifically called out issues with version mismatching impacting the dev team’s productivity in the other thread. Which is a fair rationale, but not the ideal way to resolve the root problem, as discussed in the other thread.