Discourse לא מספקת גרסת LTS

כללי
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 לייקים
2

העברתי זאת לנושא משלה, נראה שאינו קשור לאריזה של תוספים.

3 לייקים
3

אם ניקח בחשבון את הפרצוף העצוב בלוח המחוונים של הניהול לעומת היותנו כל כך הרבה קומיטים מאחור ב"עדכון דיסקוס"
האם העדכון הקריטי הוא חלק מ-tests-passed ואם אתה “מעדכן הכל” מיד לאחר פרצוף שמח לפרצוף עצוב, תהיה מסונכרן עם tests-passed

4

אני חושב שהעדכון הספציפי הזה דורש בנייה מחדש מהקונסולה. פעמיים.

לייק 1
5

לדיסקוס יש מהירות גבוהה למדי מבחינת שינויים ומפת דרכים שאפתנית.

כדי לתמוך בכך, הוא זקוק להרבה משוב משתמשים. אני חושב שיש אסטרטגיה מרומזת ברורה לקידום tests-passed מכיוון שזה תומך במשוב מוקדם על שינויים חדשים.

בתמורה, המשתמש מקבל תוכנה חינמית ותכונות חדשות. זה סוג של הסכם. אני חושב שעם הזמן ההסכם הזה הוכח כמוצלח.

גרסה יציבה לא באמת עוזרת לפיתוח רבות, כך שלא בהכרח באינטרס העסקי לקדם אותה רבות (זו רק דעתי, איני מייצג את CDCK כלל).

הבעיה האחרת עם גרסה יציבה היא זו, והיא אפילו משמעותית יותר:

בדרך כלל יש הרבה שינויים בין גרסאות יציבות, כולל השמטות משמעותיות ושינויי API. מעורבות ב-tests-passed כמפתח, מנהל אתר או יוצר ערכות נושא נותנת לך הזדמנות להתמודד עם שינויים בחלקים קטנים וניתנים לעיכול, במקום להיתקל בהר ענק בכל פעם שאתה מגיע לאבן הדרך היציבה הבאה.

כדי לתמוך בקפיצות הגדולות הללו, סביר להניח שתזדקק לאתר בימוי (staging site) ומספר רב של מקרי בדיקה לעבור עליהם.

אם אינך הבעלים של התאמות אישיות כלשהן, ייתכן שתבחר בגרסה יציבה, אך אתה מסתמך במידה רבה על אחרים שעליהם אין לך השפעה חזקה כדי להבטיח שהתוספים שבהם אתה משתמש מתוחזקים כראוי לשדרוג הבא שלך. ייתכן שתגלה שאלמנטים מסוימים מאבדים תמיכה עד שתגיע לשדרוג, ובאותה נקודה ייתכן שתמצא את עצמך בבעיה. ייתכן גם שתגלה שהמפתח אינו תומך כלל בגרסה יציבה וייתכן שתצטרך לבצע fork ולהכין “גזירה” של התוסף כדי לתמוך בגרסה היציבה שלך. (עם זאת, יש מערכת pinning טובה במקום, כך שזה לא כמות עבודה עצומה)

הדבר המשמעותי האחר בדיסקוס הוא שהוא אינטנסיבי מאוד בבדיקות יחידה, כך שהענף test-passed הוא בדרך כלל טוב מאוד מבחינת יציבות.

4 לייקים
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

ההנהלה ציינה ספציפית בעיות עם אי-התאמת גרסאות המשפיעות על הפרודוקטיביות של צוות הפיתוח בשרשור האחר. מה שמספק רציונל הוגן, אך אינו הדרך האידיאלית לפתור את הבעיה השורשית, כפי שנדון בשרשור האחר.