# RFC: A new versioning strategy for Discourse **URL:** \ **Category:** Development\ **Tags:** dev-news\ **Created:** [September 23, 2025, 7:55am UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536 "2025-09-23T07:55:33Z")\ **Posts on this page:** 1\ **Showing post:** 28
**Author:** ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)\ **Post date:** [September 26, 2025, 9:57pm UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/28 "2025-09-26T21:57:02Z")
> [@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 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. > [@per1234](#): > > 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. 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. > [@per1234](#): > > > [@mcwumbly](#): > > > > the version numbering logic is built around the package’s API. > > Not really. The point is to communicate the nature of the release to the user. Yes really, [see](https://semver.org/) > Once you identify your public API, you communicate changes to it with specific increments to your version number. --- _[View the full topic](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536)._