Van Discourse 3.2: toevoegen van -dev suffix aan bètaversies in actieve ontwikkeling

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

Als alleen al het nummeren van de versies zo complex is (om toe te wijzen en te begrijpen door gebruikers zoals ik), hoe complex zou softwareontwikkeling dan wel niet zijn!!!

Nadat ik ongeveer 15 minuten heb besteed aan alles over deze bèta, stabiele, dev, tests-passed, backuporting, heb ik het uiteindelijk opgegeven.

Wat in hemelsnaam! Laat mijn website maar ‘Dev’ blijven tonen!!