From Discourse 3.2: adding -dev suffix to beta versions under active development

AI-generated summary

Starting with Discourse 3.2.0.beta1-dev, beta versions under active development will include a -dev suffix in their version numbers (e.g., 3.2.0.beta1-dev), which will be removed only when officially released (e.g., 3.2.0.beta1). This change addresses ambiguity in version pinning and streamlines development by avoiding redundant beta1 releases. The suffix is invisible in the UI but visible on /admin as noted by Jonathan5. The versioning strategy is illustrated with Mermaid diagrams for both major and minor releases, showing how main (or tests-passed) and stable branches evolve. Rake tasks automate the process. Some users, like Bathinda, find the system overly complex and humorously concede to letting their site show ‘Dev’ rather than decipher it.

On tests-passed, starting with 3.2.0.beta1-dev, Discourse core version numbers will include a -dev suffix to indicate that they’re not the final ‘release’ versions of a beta. This suffix doesn’t appear in the UI, so this is a technicality which will have no impact on the vast majority of people.

For the technical details, see below:


In the beta series for Discourse 3.1 and below, our versioning strategy was to ‘release’ a beta, and then leave the version number in tests-passed exactly the same until the next beta release. This came with a few problems

  1. When trying to specify a version, a version like 3.1.0.beta2 could refer to hundreds of possible points in time. This is particularly problematic when trying to precisely define compatibility via .discourse-compatibility files

  2. After a major version, we had to immediately ‘release’ beta1 of the next version in order to continue development on tests-passed. This is why we had redundant beta1 releases

To improve the situation, we will now be appending -dev to the version number during development of a beta release. So for example, we’re starting the 3.2 development cycle with 3.2.0.beta1-dev. When that’s ready to be released, it will be stamped as 3.2.0.beta1, and then we’ll followup immediately with another commit to start development of 3.2.0.beta2-dev.

Going forward, we intend ‘major releases’ to look something like this:

    %%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
    gitGraph
       branch stable order: 1
       commit tag: "v3.1.8"
       checkout main
       commit id: "bump to v3.2.0.beta17" tag: "v3.2.0.beta17" type: HIGHLIGHT
       commit id: "bump to v3.2.0.beta18-dev"
       commit
       commit id: "bump to v3.2.0.beta18" tag: "v3.2.0.beta18" type: HIGHLIGHT
       checkout stable
       merge main id: "merge"
       commit id: "bump to v3.2.0" type: HIGHLIGHT tag: "v3.2.0"
       checkout main
       commit id: "bump to v3.3.0.beta1-dev"

‘minor releases’ will look something like

    %%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
    gitGraph
       branch stable order: 1
       commit tag: "v3.1.1"
       checkout main
       commit id: "bump to v3.2.0.beta2-dev"
       commit id: "... development of beta2 ..."
       commit id: "bump to v3.2.0.beta2" tag: "v3.2.0.beta2" type: HIGHLIGHT
       checkout stable
       commit id: "backports"
       commit id: "bump to v3.1.2" type: HIGHLIGHT tag: "v3.1.2"
       checkout main
       commit id: "bump to v3.2.0.beta3-dev"

(main and tests-passed can be considered equivalent in these diagrams)

These processes have been codified into some rake tasks which can be found in version_bump.rake.

31 Likes

It does appear on the /admin page… but finding this topic set my mind at rest.

1 Like

If just the numbering the versions is so complex (to assign and to be understood by users like me), how complex its software development would be!!!

After spending around 15 minutes, about all this beta, stable, dev, tests-passed, backporting, i finally quit.

What the heck! Let my website keep showing ‘Dev’!!