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

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’!!