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

documentation developers
1

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. (hence, this is not an announcements topic)

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.

26 Likes
2

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

1 Like