ci: bump minor for breaking changes while pre-1.0, add version override (#86)

* ci: bump minor for breaking changes while pre-1.0, add version override

Semver 0.x: anything may change, so a `!`/BREAKING CHANGE marker bumps
MINOR while the current major is 0 (release-please calls this
bump-minor-pre-major). Without this, the honest `feat!:` on #84
computed 1.0.0 — a major release nobody asked for (release PR #85,
closed unmerged).

Cutting 1.0.0 (and any later major) is now a deliberate act: dispatch
the workflow with the new version-override input, which skips the
conventional-commit computation after validating MAJOR.MINOR.PATCH.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* ci: pass version-override via env, document pre-1.0 bump rule

- version-override reaches the compute script through an env entry
  instead of inline ${{ }} interpolation, so the input value can't be
  interpreted as shell syntax
- CONTRIBUTING.md commit-conventions table now documents the pre-1.0
  rule: breaking markers bump minor while on 0.x, and 1.0.0 is cut
  deliberately via the version-override dispatch input; post-1.0 the
  major-bump row applies unchanged

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: gyenese.matyas <gyenese.matyas@novaservices.hu>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Author: 3 people

.github/workflows/create-release.yml

@@ -2,6 +2,16 @@ name: Create Release
 
 on:
   workflow_dispatch:
+    inputs:
+      version-override:
+        description: >-
+          Exact version to release (MAJOR.MINOR.PATCH), skipping the
+          conventional-commit bump computation. Required to cut 1.0.0:
+          while the current version is 0.x, breaking changes only bump
+          the minor version, so a major release is always a deliberate,
+          manually-typed act.
+        required: false
+        type: string
 
 permissions:
   contents: write
@@ -18,6 +28,10 @@ jobs:
 
       - name: Compute next version
         id: version
+        env:
+          # Passed via env instead of inline ${{ }} interpolation so the input
+          # value can't be interpreted as shell syntax inside the script.
+          VERSION_OVERRIDE: ${{ inputs.version-override }}
         run: |
           CURRENT=$(jq -r '.["."]' .release-please-manifest.json)
           SUFFIX=$(echo "$CURRENT" | sed 's/^[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*//')
@@ -50,8 +64,22 @@ jobs:
             COMMITS=$(git log --pretty=format:'%s%n%b')
           fi
 
-          if echo "$COMMITS" | grep -qE '^\* [a-z]+(\([^)]+\))?!:|^[a-z]+(\([^)]+\))?!:|BREAKING CHANGE'; then
-            NEXT="$((MAJOR+1)).0.0${SUFFIX}"
+          OVERRIDE="$VERSION_OVERRIDE"
+          if [ -n "$OVERRIDE" ]; then
+            if ! echo "$OVERRIDE" | grep -qE '^[0-9]+\.[0-9]+\.[0-9]+$'; then
+              echo "version-override '$OVERRIDE' is not MAJOR.MINOR.PATCH" >&2
+              exit 1
+            fi
+            NEXT="$OVERRIDE"
+          elif echo "$COMMITS" | grep -qE '^\* [a-z]+(\([^)]+\))?!:|^[a-z]+(\([^)]+\))?!:|BREAKING CHANGE'; then
+            if [ "$MAJOR" -eq 0 ]; then
+              # Pre-1.0 (semver 0.x: "anything may change"): breaking changes
+              # bump MINOR. Cutting 1.0.0 is a deliberate act via the
+              # version-override input above, never an accident of a `!` marker.
+              NEXT="${MAJOR}.$((MINOR+1)).0${SUFFIX}"
+            else
+              NEXT="$((MAJOR+1)).0.0${SUFFIX}"
+            fi
           elif echo "$COMMITS" | grep -qE '^\* feat(\([^)]+\))?:|^feat(\([^)]+\))?:'; then
             NEXT="${MAJOR}.$((MINOR+1)).0${SUFFIX}"
           else

CONTRIBUTING.md

@@ -53,12 +53,19 @@ Kraft uses [Conventional Commits](https://www.conventionalcommits.org/). The com
 |--------|---------|-------------|
 | `fix:` | Bug fix | Patch (0.0.X) |
 | `feat:` | New feature | Minor (0.X.0) |
-| `feat!:` or `BREAKING CHANGE:` | Breaking change | Major (X.0.0) |
+| `feat!:` or `BREAKING CHANGE:` | Breaking change | Major (X.0.0) — **minor while pre-1.0, see below** |
 | `docs:` | Documentation only | No release |
 | `refactor:` | Code restructuring | No release |
 | `test:` | Adding/fixing tests | No release |
 | `ci:` | CI/CD changes | No release |
 
+> **Pre-1.0 rule:** while the project version is `0.x`, breaking changes (`!` suffix or
+> `BREAKING CHANGE:`) bump the **minor** version, not the major — per semver, 0.x makes
+> no stability promise, and 1.0.0 must never happen as a side effect of a commit marker.
+> Cutting `1.0.0` (or any later major ahead of schedule) is a deliberate act: dispatch
+> the **Create Release** workflow with its `version-override` input set to the exact
+> version. After 1.0, breaking changes bump the major version as the table says.
+
 Examples:
 ```text
 fix: resolve nullable nested property codegen