Background

Currently all development happens on main. We introduce release branches to enable patch releases, downstream version coordination, and multi-line maintenance.

Task

Adopt the X.Y.x branch convention, widely used by Spring and others. Start with this and refine as we go.

• Create 0.1.x branch from d7e8431 (stable in the internal codebase)
• Update gradle.properties to 0.1.0 on 0.1.x
• Tag as v0.1.0
• Bump main to 0.2.0-SNAPSHOT (Bump version to 0.2.0-SNAPSHOT #208)

Branch naming

Use X.Y.x format. Example: 0.1.x, 0.2.x

Versioning

Follow SemVer. Use -SNAPSHOT suffix during development.

0.1.0-SNAPSHOT → 0.1.0 (release) → 0.1.1-SNAPSHOT → 0.1.1 (patch)

Release flow

main:    A ─ B ─ C ─ D ─ E ─ ...
                 │
          tag v0.1.0
                 └── 0.1.x:  C ── D' (cherry-pick) ── tag v0.1.1

Release

From main:

1. 0.1.0-SNAPSHOT → 0.1.0, tag v0.1.0
2. Create 0.1.x branch from tag, bump to 0.1.1-SNAPSHOT
3. Bump main to 0.2.0-SNAPSHOT

Patch release

From X.Y.x branch:

1. Merge fix to main first
2. Cherry-pick to 0.1.x
3. 0.1.1-SNAPSHOT → 0.1.1, tag v0.1.1
4. Bump to 0.1.2-SNAPSHOT

Upstream-first

Fixes go to main first, then cherry-pick to release branches.

✅  main → cherry-pick → 0.1.x
❌  commit directly to 0.1.x only

Exception: when main has diverged significantly and cherry-pick is not feasible, apply directly to the release branch. Document the reason in the commit message.

Support policy and artifacts

During 0.x.x, only the latest release line is supported. Artifacts are tags only. Details to be defined after 1.0.0.