Merge pull request #349 from WISE-Developers/dev

Promote dev → main: versioning scheme now patch-on-dev, minor-on-main (#348)

Author: spydmobile

.github/dev-build-count

@@ -1,23 +1,27 @@
 #!/bin/bash
 # determine-bump.sh <pr_number>
-# Scans commits in a PR for issue references, checks GitHub issue labels,
-# and returns the appropriate semver bump level.
+# Returns the semver bump level for a merge into main.
 #
-# Returns: patch | minor | major
+# Returns: minor | major
 #
-# Logic:
-#   1. PR has label "release:major" → major
-#   2. Any referenced issue has label "feature" or "enhancement" → minor
-#   3. Otherwise → patch (default, safe)
+# Versioning scheme (#348):
+#   - Changes on dev bump PATCH   (handled by dev-release.yml, not here)
+#   - A PR merged into main bumps MINOR — that is what a release is
+#   - Unless the PR carries the label "release:major", which bumps MAJOR
 #
-# Required env vars: GH_TOKEN, PR_LABELS (JSON array), REPO
+# The patch digit therefore counts changes accumulated during development
+# (0.5.13 = thirteen changes on the 0.5.x line) and the minor digit identifies
+# the release.
+#
+# Previously this read the labels of every issue referenced in the PR's commit
+# messages and returned minor for "feature"/"enhancement", patch otherwise. That
+# made the released version depend on issue labelling rather than on the release
+# itself, and produced v0.13.1 where v0.14.0 was meant.
+#
+# Required env vars: GH_TOKEN, REPO
 set -euo pipefail
 
 PR_NUMBER="${1:-}"
-if [[ -z "$PR_NUMBER" ]]; then
-    echo "patch"
-    exit 0
-fi
 
 if [[ -z "${GH_TOKEN:-}" ]]; then
     echo "ERROR: GH_TOKEN environment variable required" >&2
@@ -29,56 +33,30 @@ if [[ -z "${REPO:-}" ]]; then
     exit 1
 fi
 
-# Step 1: Check for manual major override via PR label
-if echo "${PR_LABELS:-[]}" | grep -q '"release:major"'; then
-    echo "major"
+# No PR found (e.g. a direct push to main). A release is still a release, so
+# minor remains the correct level.
+if [[ -z "$PR_NUMBER" ]]; then
+    echo "minor"
     exit 0
 fi
 
-# Step 2: Get commits from this PR via GitHub API
-COMMITS_JSON=$(curl -sf \
+# Read the PR's own labels. This used to consult $PR_LABELS, which
+# stable-release.yml never set — so the major override could never fire.
+LABELS_JSON=$(curl -sf \
     -H "Authorization: Bearer $GH_TOKEN" \
     -H "Accept: application/vnd.github.v3+json" \
-    "https://api.github.com/repos/${REPO}/pulls/${PR_NUMBER}/commits?per_page=100" \
-    || echo "[]")
+    "https://api.github.com/repos/${REPO}/pulls/${PR_NUMBER}" \
+    || echo '{"labels":[]}')
 
-# Step 3: Extract all #NNN issue references from commit messages
-ISSUE_NUMBERS=$(echo "$COMMITS_JSON" | \
+HAS_MAJOR=$(echo "$LABELS_JSON" | \
     node -e "
         const data = JSON.parse(require('fs').readFileSync('/dev/stdin', 'utf8'));
-        const msgs = data.map(c => c.commit.message).join(' ');
-        const matches = msgs.match(/#(\d+)/g) || [];
-        const unique = [...new Set(matches.map(m => m.slice(1)))];
-        unique.forEach(n => console.log(n));
+        const labels = (data.labels || []).map(l => l.name);
+        console.log(labels.includes('release:major') ? 'yes' : 'no');
     ")
 
-if [[ -z "$ISSUE_NUMBERS" ]]; then
-    echo "patch"
-    exit 0
+if [[ "$HAS_MAJOR" == "yes" ]]; then
+    echo "major"
+else
+    echo "minor"
 fi
-
-# Step 4: Check labels on each referenced issue
-BUMP_LEVEL="patch"
-
-for ISSUE_NUM in $ISSUE_NUMBERS; do
-    LABELS_JSON=$(curl -sf \
-        -H "Authorization: Bearer $GH_TOKEN" \
-        -H "Accept: application/vnd.github.v3+json" \
-        "https://api.github.com/repos/${REPO}/issues/${ISSUE_NUM}" \
-        || echo '{"labels":[]}')
-
-    HAS_FEATURE=$(echo "$LABELS_JSON" | \
-        node -e "
-            const data = JSON.parse(require('fs').readFileSync('/dev/stdin', 'utf8'));
-            const labels = (data.labels || []).map(l => l.name);
-            const isFeature = labels.some(l => l === 'feature' || l === 'enhancement');
-            console.log(isFeature ? 'yes' : 'no');
-        ")
-
-    if [[ "$HAS_FEATURE" == "yes" ]]; then
-        BUMP_LEVEL="minor"
-        break
-    fi
-done
-
-echo "$BUMP_LEVEL"

.github/scripts/determine-bump.sh

@@ -23,24 +23,27 @@ jobs:
         with:
           node-version: '22'
 
-      - name: Increment dev build counter
+      - name: Bump patch version
         id: version
         run: |
-          CURRENT=$(node -p "require('./frontend/package.json').version")
-          COUNT_FILE=".github/dev-build-count"
-          BUILD_NUMBER=$(( $(cat "$COUNT_FILE") + 1 ))
-          echo "$BUILD_NUMBER" > "$COUNT_FILE"
-          DEV_TAG="v${CURRENT}-dev.${BUILD_NUMBER}"
-          echo "current=${CURRENT}" >> $GITHUB_OUTPUT
-          echo "tag=${DEV_TAG}" >> $GITHUB_OUTPUT
-          echo "build_number=${BUILD_NUMBER}" >> $GITHUB_OUTPUT
+          # Every change on dev bumps PATCH (#348). The patch digit counts the
+          # changes accumulated on the current line: 0.5.13 means thirteen
+          # changes since 0.5.0. Merging to main then bumps MINOR, which is the
+          # release.
+          PREVIOUS=$(node -p "require('./frontend/package.json').version")
+          chmod +x .github/scripts/bump-version.sh
+          NEW_VERSION=$(.github/scripts/bump-version.sh patch)
+          echo "previous=${PREVIOUS}" >> $GITHUB_OUTPUT
+          echo "current=${NEW_VERSION}" >> $GITHUB_OUTPUT
+          echo "tag=v${NEW_VERSION}" >> $GITHUB_OUTPUT
+          echo "Dev version: v${PREVIOUS} -> v${NEW_VERSION}"
 
-      - name: Commit build counter
+      - name: Commit version bump
         run: |
           git config user.name "github-actions[bot]"
           git config user.email "github-actions[bot]@users.noreply.github.com"
-          git add .github/dev-build-count
-          git commit -m "chore: dev build ${{ steps.version.outputs.build_number }} [skip ci]"
+          git add frontend/package.json
+          git commit -m "chore: dev v${{ steps.version.outputs.current }} [skip ci]"
           git push
 
       - name: Install dependencies
@@ -67,6 +70,5 @@ jobs:
             **Unstable pre-release** — not for production use.
 
             Branch: `dev`
-            Build: `${{ steps.version.outputs.build_number }}`
-            Base version: `v${{ steps.version.outputs.current }}`
+            Version: `v${{ steps.version.outputs.current }}` (was `v${{ steps.version.outputs.previous }}`)
             Commit: `${{ github.sha }}`

.github/workflows/dev-release.yml

@@ -94,12 +94,12 @@ jobs:
           generate_release_notes: true
           files: frontend/nomad-frontend-*.tgz
 
-      - name: Sync version back to dev and reset build counter
+      - name: Sync released version back to dev
         run: |
+          # dev continues patch-bumping from the released version: after v0.6.0
+          # the next change on dev is v0.6.1 (#348). There is no build counter
+          # to reset any more - dev carries real versions.
           git fetch origin dev
           git checkout dev
           git merge main -m "chore: sync v${{ steps.newversion.outputs.version }} from main [skip ci]"
-          echo "0" > .github/dev-build-count
-          git add .github/dev-build-count
-          git commit -m "chore: reset dev build counter after v${{ steps.newversion.outputs.version }} [skip ci]"
           git push origin dev

.github/workflows/stable-release.yml

@@ -68,26 +68,28 @@ Then create a PR on GitHub targeting the `dev` branch.
 
 ### 5. What Happens After Merge
 
-When your PR is merged into `dev`, an **unstable pre-release** is automatically built and published to GitHub Releases. These are tagged like `v0.3.0-dev.47` and marked as pre-releases.
+When your change is merged into `dev`, the **patch** version is bumped and an **unstable pre-release** is automatically built and published to GitHub Releases, tagged with that version (e.g. `v0.13.2`) and marked as a pre-release.
 
 ## How Releases Work
 
 ### Unstable (dev)
 
-Every merge to `dev` triggers an automatic pre-release build. No version bump occurs in `package.json` — the artifact is tagged with a build number (`v0.3.0-dev.47`). These builds are for testing and are not intended for production.
+Every merge to `dev` bumps the **patch** version in `frontend/package.json` and publishes a pre-release. The patch digit counts the changes accumulated on the current line: `0.5.13` means thirteen changes since `0.5.0`. These builds are for testing and are not intended for production.
 
 ### Stable (main)
 
 When the maintainer is ready to cut a stable release, they open a PR from `dev` to `main`. On merge, the CI automation:
 
-1. Scans all commits in the PR for issue references (`#NNN`)
-2. Checks the labels on each referenced issue via the GitHub API
-3. Determines the version bump:
-   - Any issue labeled `feature` or `enhancement` → **minor** bump
-   - Only `bug`/`task` labels or no issue references → **patch** bump
-   - PR labeled `release:major` → **major** bump (manual override)
-4. Bumps the version in `frontend/package.json`
-5. Creates a git tag and GitHub Release with the built tarball
+1. Bumps the **minor** version in `frontend/package.json` — a merge to `main` *is* the release,
+   so `0.5.13` becomes `0.6.0`. The patch digit resets, and the minor digit identifies the
+   released line.
+   - Unless the PR is labeled `release:major`, which bumps **major** instead (manual override)
+2. Regenerates `CHANGES.md` from git history
+3. Creates a git tag and GitHub Release with the built tarball
+4. Merges the released version back into `dev`, so development continues from `0.6.1`
+
+The bump level does **not** depend on issue labels. It previously did, which meant a release's
+version was decided by how issues happened to be labelled rather than by the release itself (#348).
 
 ### LTS (lts)
 

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 {
   "name": "@nomad/frontend",
-  "version": "0.13.1",
+  "version": "0.13.2",
   "description": "Project Nomad - Fire Modeling GUI",
   "private": false,
   "type": "module",