We’re planning to introduce a new versioning system for Discourse. Our goal is to provide more choice & predictability for community administrators, while maintaining our development velocity. We’re also adjusting some terminology to align better with other software. This document will evolve as we…

It’s not about when the theme/plugin author pushes a fix, it’s about when Discourse core has a security fix. Per [صورة] david: Approximately every 6 months, declare one of those releases as an Extended Support Release (ESR). ESR versions remain supported for 2 releases after the next ESR is de…

[صورة] schneeland: What’s not quite clear to me yet is how the upgrade process will work for the release and esr branches (latest seems straight-forward). With the current launcher tooling, and this new branch structure, you could have control over upgrade timing by doing something like: v2…

[صورة] schneeland: My understanding based on the previous posts was that the creation of a release version branch would automatically trigger the creation of a plugin branch for that version It’s up to the plugin/theme author here. Either they can continue with the current strategy, where the…

[صورة] RGJ: It’s not about when the theme/plugin author pushes a fix, it’s about when Discourse core has a security fix. Ok, but I think then I understand the problem even less :confused: Ultimately, it doesn’t really matter as per @david ‘s latest comments, so just to wrap it up. The propos…

[صورة] david: With the current launcher tooling, and this new branch structure, you could have control over upgrade timing by doing something like: … But manually editing that app.yml every month is really not ideal, so hopefully we’ll be able to design a system which makes the process more us…

I don’t see any benefit to this year-based versioning scheme you propose. Stick with the SemVer compliant version numbers!

SemVer itself isn’t really designed for large applications. I understand it to be much more targeted at libraries consumed by software, and in particular, the version numbering logic is built around the package’s API. We could apply semver to our API(s), though. Having stronger guarantees around th…

[صورة] mcwumbly: I think the “leading zeroes” suggestion is the only thing that we would be breaking from if we go that route. The OP says that you’re not using leading zeros, if I understand correctly. [صورة] david: e.g. the first release of 2026 would be v2026.0, next would be v2026.1,…

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 da…

[صورة] pfaffman: The OP says that you’re not using leading zeros, if I understand correctly. I proposed that a few posts up. [صورة] per1234: version number having meaning instead of just being some arbitrary number, as is the case with your proposal. Contrary to semver, the proposed v…

RFC: استراتيجية إصدار جديدة لـ Discourse

مطور

per1234 26 سبتمبر 2025، 4:06م 24

لا أرى أي فائدة لمخطط الإصدارات المستند إلى السنة الذي تقترحه. التزم بأرقام الإصدارات المتوافقة مع SemVer!

الموضوع		الردود	مرات العرض
January 2026 Releases Announcements release-notes	15	1803	3 فبراير 2026
July 2026 monthly release Announcements release-notes	13	779	29 يوليو 2026
Stable branch compatibility with discourse_docker and plugins Self-hosting stable	37	3122	3 فبراير 2024
Jumping from 2026.1 ESR to 2026.7 - What I found Product Support	6	456	12 سبتمبر 2026
Enable updates only to a given release UX	28	3553	25 يناير 2017

RFC: استراتيجية إصدار جديدة لـ Discourse

الموضوعات ذات الصلة