Ok, but I think then I understand the problem even less
Ultimately, it doesn’t really matter as per @david‘s latest comments, so just to wrap it up.
The proposed model is monthly release, plus 2 esr versions, so e.g. for 2026:
2026.1
2026.2
2026.3
…
2026.8
2026.9
2026.10
…
So assuming we are in October 2026 and .2 and and .8 are esr versions, that means 4 supported versions.
And my thought was. Wouldn’t it be easier to basically have quarterly versions, i.e. for 2026:
2026.1
2026.2
2026.3
…
And still only the current one and the previous release would be supported, so in October 2026, it would be 2.
And the whole reasoning was that maybe this would make it easier for both developers and users. But as mentioned above: @david has clarified that less frequent releases are not an option.
Understood. That is roughly how I expected it. Indeed, in this case a bit of tool support would be nice at least mid-term.
The way I conceptualise it, is: you are on a specific release channel (latest, release, esr), and usually you would relatively quickly move to the next release, so getting a message and/or notification when the new release is available and having a single command to switch to it would be neat. And for cases, in which you have delayed the adoption of a new release, it would also be nice to be reminded when the currently used release becomes obsolete/unsupported. Bonus points if the respective tool could also let you switch release channels quickly
But I understand if that’s not the top priority right now, and you still recommend people to stay on test-passed/latest.
I see. In the context of my work, getting out a feature to customers is considered “fast”
Also, as mentioned above, my thought was that moving to a quarterly schedule would actually make your life (and the life of plugin/theme developers) easier, because there’s less branches under maintenance. So if that’s not the case, then I guess that really doesn’t make sense for you
SemVer כשלעצמו אינו מיועד ליישומים גדולים. אני מבין שהוא מכוון הרבה יותר לספריות הנצרכות על ידי תוכנה, ובפרט, הלוגיקה של מספור הגרסאות בנויה סביב ה-API של החבילה.
אנו יכולים ליישם SemVer על ה-API שלנו. קבלת הבטחות חזקות יותר סביב ה-APIs ש-Discourse חושף היא בהחלט שיחה שכדאי לנהל, אבל אני חושב שהיא נפרדת מזו.
עכשיו, אני מבין שלא אמרת שעלינו להיות תואמים ל-SemVer – רק אמרת שעלינו להמשיך להשתמש במספרים שתואמים למערכת המספור שצוינה על ידי SemVer.
מספר גרסה רגיל חייב להיות בצורה X.Y.Z כאשר X, Y ו-Z הם מספרים שלמים שאינם שליליים, וחייבים לא להכיל אפסים מובילים. X הוא הגרסה הראשית, Y הוא הגרסה המשנית, ו-Z הוא גרסת התיקון. כל רכיב חייב לגדול מספרית. לדוגמה: 1.9.0 → 1.10.0 → 1.11.0.
אני חושב שההצעה “אפסים מובילים” היא הדבר היחיד שנפרק אם נלך בדרך זו.
אחרת, אני חושב שכל ספריית SemVer עדיין תוכל לנתח את מספרי הגרסאות שאנו מציעים ולסדר אותם כראוי.
כל זה בצד, האם תוכל לשתף עוד לגבי הסיבה שבגללה אתה חושב שלתאימות למערכת מספור SemVer יש ערך?
The OP says that you’re not using leading zeros, if I understand correctly.
I think also a compelling reason to use leading zeros (sorting by versions) has been proposed. Are leading zeros the current plan? (I still like month-versions rather than serial versions).
The point of SemVer is that the version number should communicate some useful information. The only information communicated by your proposed scheme is the earth’s orbit around the sun. That information is not very useful to the consumer of the software.
If for some reason I did want to know the date of the release, I would look at the release and get the full date.
Not really. The point is to communicate the nature of the release to the user.
If the release is a patch version bump, this is communicating that the changeset doesn’t contain anything that is expected to affect the workflow of the users of the software.
If the release is a minor version bump, this is communicating that the changeset includes the addition of new user facing components, but nothing that will break existing workflows of the users of the software.
If the release is a major version bump, this is communicating that the changeset includes changes that may break existing workflows of the users of the software.
The determination of which of the version components should be bumped is more clear cut in a software product that has a single user interface, but the principles remain the same even for a software product like Discourse where there are a variety of levels of interfaces and types of consumers (e.g., plugin developers, API consumers, forum staff, end users).
Even if the choice of which component to bump is a bit more subjective in this software project, it still results in the version number having meaning instead of just being some arbitrary number, as is the case with your proposal.
Contrary to semver, the proposed version numbering scheme makes it immediately clear if a version is still supported (like Ubuntu). Since that depends on the earth’s orbit around the sun as well, this actually makes sense.
This is clearly targeted towards packages and libraries. Any discourse release includes changes that may break existing workflows of the users of the software. I’ve even seen security patches do that. Semver is not usable for complex applications.
Just to emphasize a point that might get lost, I think Discourse does great here. One improvement would be to at least highlight the topics you’ve already written that describe changes and potential breakage within that upgrade cycle. For example, with the 3.5 release, I had to open the release notes, click through to the blog, and then happen to click on the link about bundling plugins with Discourse core in order to catch that detail that leaving those plugins within my config file could impact upgrades.
It’d be great to pull those kinds of notes out onto a page/topic for ESR releases, even if it’s just a set of links to existing topics that should be reviewed prior to performing an ESR upgrade.
This may be beyond the scope of this thread though - my feedback on the versioning change is that I welcome it and appreciate the transparency here. I think this would be a great improvement that would simplify things while giving us more options for self-hosting.
That is not the important information for a forum maintainer evaluating a new release.
No, really. You are missing the actual point of SemVer by refusing to understand that “API” actually just means the interface. There is absolutely no reason the spirit of SemVer can not be used in versioning of any type of software.
לא באמת משנה אם מדובר בספרייה או באפליקציה גדולה. סכימת גרסאות סמנטית עובדת מצוין עבור אפליקציה גדולה. היא יכולה אפילו לשמש לאוסף של אפליקציות המקובצות לפלטפורמה, אך כאן זה הופך להיות די קשה להתמודדות.
השאלה העיקרית היא האם אתה הולך במסלול של deprecation (הפסקת שימוש) נתמך במהדורה אחת, ורק הסרה שלו במהדורה ראשית הבאה. קיום פונקציונליות שהופסקה אך עדיין נתמכת, יכול לקחת לא מעט מאמץ. כאשר אתה עומד לבצע שינויים במודל הנתונים השמור שלך, הפסקת שימוש יכולה לעיתים קרובות להפוך לבלתי אפשרית. אם זה קורה, אתה אפילו לא יכול לעשות גרסה מינורית עם פונקציונליות שהופסקה, ואתה קופץ מיד לגרסה ראשית הבאה. זה החלק שבו אפליקציות גדולות בדרך כלל נתקלות בבעיות. אתה עובר מ-3.0.0 ל-3.0.1 ל-4.0.0 מכיוון שאינך יכול לספק תאימות לאחור. אם יש לך לעיתים קרובות שינויים שוברים (breaking changes), היצמדות ל-semver מוסיפה מעט ערך.
עם זאת. אני הרבה יותר מעדיף את המבנה הזה מכיוון שהוא מתקשר בצורה ברורה יותר למפתחים שיהיו שינויים שוברים. סכימת YYYY.N לא אומרת לי כלום כמפתח, ולא כלום כמנהל מערכת.
לכן השאלה היא, מה אתה רוצה לתקשר עם הגרסה? אם אתה רוצה לעשות 6 מהדורות תכונה (feature releases) (שיכולות להיות שוברות או לא), ובכל מהדורה שישית תהיה תמיכה ארוכה יותר עם תיקונים (patches); ואתה לא רוצה לתת גרסאות למהדורות תיקון. אז X.Y היא סכימה מתאימה, כאשר Y=0 היא זו הנתמכת לאורך זמן. X יהיה פשוט מספר. הבעיה היא כאשר X הוא השנה, אז Y משויך במהירות לחודש. אז מהדורות נתמכות לאורך זמן חדשות ישוחררו בינואר? אני תמיד צריך לבדוק איזו גרסת אובונטו היא LTS, מה שמעצבן אותי.
אז מה אם Discourse פשוט ימשיך עם הגרסה הראשית הנוכחית. הגרסה הנתמכת לאורך זמן הבאה נקראת 4.0; ואז נקבל 4.1 עד 4.5 כמהדורות תכונה; ואחריהן 5.0 שהיא החדשה ביותר הנתמכת לאורך זמן.
אז גם לא יהיה לך את הרגע המביך הזה שבו מהדורה מתעכבת בגלל בעיה גדולה.
אתה יכול אופציונלית להוסיף מספר “תיקון” (patch) אם אתה מתכנן לשחרר תיקונים במפורש (במקום שיהיו תיקונים מתגלגלים). “אבל אז יש לך x.y.z שזה semver”. ובכן, לא, זה נראה כמו semver, אבל זה לא. כל מהדורת “מינור” חדשה יכולה להיות שוברת. לכן אני מציע פשוט להיצמד לסכימת גרסה X.Y עם Y=0 → LTS.
מחרוזת הגרסה בצד. אני כן אוהב את תוכנית השחרור החדשה.
This discussion doesn’t look good. I can see a decision from the development team to embrace a new versioning system that make sense for them, and others who suddenly seem to consider that Discourse version was following semantic versioning… which it was not. It’s always been a rolling release, at least since 1.0, or?
But the arguments on all sides of the debate seem flawed:
“industry standard”: Linux is using even majors for stable, and odd majors for developing.
“earth orbiting around the Sun”: well, if you convert to Islam, you’ll get into trouble because you’ll drop versions and no, it won’t match the Sun revolution anymore, but the Moon cycles. Here, you now understand that by choosing YYYY.Y.Z versioning scheme over X.Y.Z, you enforced a dominant culture.
Minor release remains unclear: you mention “assuming a monthly cadence”, but it could be as well 3 weeks or 7, depending on the functionality, in which case counting Y from 0 makes sense, or are you actually aiming to release monthly, in which case counting M from 1 would make more sense?
The main change I see is that by adopting a monthly pace, the Discourse team is setting expectations and moving away from release targets, embracing regular releases instead.
LTS for 8 months does not really sound “long”. NodeJS is moving too fast, but they keep LTS support over 30 months and a few current versions at once, while Ubuntu keeps LTS over years. Although I understand that Discourse is neither a language nor an OS, it seems to announce that new functionality will ship at quite fast a pace, which brings another issue to mind: since new admin settings are introduced every now and then, we’ll soon get into the Wordpress hell with infinite options and unfathomable complication for site administration, aka bloatware: it becomes important then to clarify how you go from existing releases with targets to regular releases, and how do you choose which targets to drop (or postpone) for a release, etc. (which may already be documented, but I missed that one.)
Would you be so kind to share your rationale between the pace of development / versioning, and what do you have in mind to avoid admins drowning under too many settings and a heightened learning curve?
Before answering your other questions, I want to first clarify that our intended release frequency isn’t changing with this proposal.
For the past 3 years, we’ve been making “stable” releases approximately every 6 months, targeting these releases for the end of each January and July, with a bit of slippage here and there:
In this new proposal, we intend to keep the same cadence we’ve been following, with the main changes being:
What we now call “stable” releases, we’ll be calling “extended support releases”
We’ve chosen that name and not long term support, because we agree that it’s extended relative to our other supported releases, but not necessarily “long term”. This proposal doesn’t include adding a long term support release.
Currently, support for one stable release ends immediately when the next release is made. With this new proposal, support overlaps for ~2 months, so people have time to upgrade while receiving security patches
What we now call “beta” releases, we’ll be calling “releases”
We don’t currently support beta releases at all beyond their release date. They are merely checkpoints along the way that come with a notification to fast forward, as they also often include security fixes
With this proposal we do intend to support releases for ~2 months, so people can decide when to upgrade, while continuing to receive security patches
With that in mind, do you feel like your other questions about too many settings are still related to this proposal? Or are they independent concerns that would be better to discuss in a separate topic?
Thank you for your thorough explanation @mcwumbly!
Indeed, this is a different concern. Customizing the admin using a plugin would be useful for making tests about what it could look like. Any ongoing work regarding such an approach?
Not specifically this, but we’ve been investing quite a bit in improving the admin UI over the past year. If you want to dig into these things more, can you start a new topic and lay out some of the problems and or ideas that you’d like to discuss more?
This is a great change (I especially like overlapping ESRs)
Feedback:
I would like to see that lifecycle graph on a centralized page so I can easily check on it, ideally with a EOL table so I can easily tell what is in and out of support at any given time and plan accordingly (at least for ESRs).
Stream switching:
This would be great – but even just being able to choose which tag during setup would be huge. Or even just include the manual steps in the setup documentation. If someone wants to start on stable/ESR, it’s really not clear how to do that right now to a new administrator. (I think the answer is pass –skip-rebuild to ./launcher, then edit the version, then do rebuild for the first time, but I’m not sure.) Since otherwise the setup just immediately launches into grabbing & running the latest version, and then going backwards is asking for trouble.
(Example of the difficulty to a new admin: Right now, the #1 search result for “install discourse stable” directs to this thread, which links to another thread which explains how to upgrade to stable, but not how to install stable from scratch.)
