מ-Free Discourse 3.2: הוספת סיומת -dev לגרסאות בטא בפיתוח פעיל

סיכום מבוסס בינה מלאכותית

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 לייקים

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

לייק 1

אם רק המספור של הגרסאות כל כך מורכב (להקצאה ולהבנה על ידי משתמשים כמוני), כמה מורכבת תהיה פיתוח התוכנה!!!

לאחר שהשקעתי כ-15 דקות, על כל הבטא, היציב, הפיתוח, הבדיקות שעברו, הגיבוי לאחור, לבסוף ויתרתי.

מה לעזאזל! תנו לאתר שלי להמשיך להציג ‘Dev’!!