Discourse levert geen LTS-release

Algemeen
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.

4 likes
2

Dit is naar een eigen onderwerp verplaatst, lijkt niet gerelateerd aan het bundelen van plugins.

3 likes
3

Als we kijken naar het verdrietige gezicht in het admin-dashboard versus zoveel commits achterliggen bij “Update discourse”

is het kritieke update-onderdeel van tests-passed en als je “Update All” onmiddellijk na een blij gezicht naar een triest gezicht uitvoert, ben je dan in sync met tests-passed?

4

Ik denk dat deze specifieke update vereist dat je opnieuw opbouwt vanuit de console. Twee keer.

1 like
5

Discourse lijkt een vrij hoge snelheid te hebben wat betreft veranderingen en een ambitieuze roadmap.

Om dat te ondersteunen is er veel gebruikersfeedback nodig. Ik denk dat er een duidelijke impliciete strategie is om tests-passed te promoten, omdat dat vroege feedback op nieuwe wijzigingen ondersteunt.

In ruil daarvoor krijgt de gebruiker gratis software en nieuwe functies. Het is een soort pact. Ik denk dat deze deal in de loop van de tijd succesvol is gebleken.

Een stabiele build helpt de ontwikkeling niet echt veel, dus het is misschien niet in het zakelijke belang om deze zoveel te promoten (alleen mijn mening, ik spreek helemaal niet voor CDCK).

Het andere probleem met stabiel is dit, en het is nog belangrijker:

Er zijn meestal veel wijzigingen tussen stabiele versies, waaronder belangrijke deprecations en API-wijzigingen. Betrokkenheid bij tests-passed als ontwikkelaar, site-beheerder of thema-maker geeft je de kans om wijzigingen in kleine, behapbare stukjes aan te pakken, in plaats van een enorme berg te moeten beklimmen telkens als je de volgende stabiele mijlpaal bereikt.

Om die grote sprongen te ondersteunen, heb je waarschijnlijk een staging-site en een reeks testgevallen nodig om door te lopen.

Als je zelf geen aanpassingen bezit, kun je kiezen voor stabiel, maar je bent sterk afhankelijk van anderen, over wie je misschien geen sterke invloed hebt, om ervoor te zorgen dat eventuele add-ons die je gebruikt voldoende worden onderhouden voor je volgende upgrade. Het kan zijn dat sommige elementen geen ondersteuning meer hebben tegen de tijd dat je gaat upgraden en op dat moment kom je misschien in de problemen. Het kan ook zijn dat de ontwikkelaar stabiel helemaal niet ondersteunt en dat je een fork moet maken en een “cut” van de plugin moet voorbereiden om je stabiele build te ondersteunen. (er is echter een goed pinning-systeem aanwezig, dus het is geen enorme hoeveelheid werk)

Het andere significante aspect van Discourse is dat het zeer intensief is met unit tests, dus de test-passed branch is meestal erg goed vanuit een stabiliteitsperspectief.

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

Het management noemde specifiek problemen met versieconflicten die de productiviteit van het ontwikkelingsteam beïnvloedden in de andere thread. Wat een eerlijke redenering is, maar niet de ideale manier om het fundamentele probleem op te lossen, zoals besproken in de andere thread.