[Devops] Branching Strategy - Phase 2.A - Internal versions

[lowlydba]

Goal

Build the version scheme foundation and CI compute logic for all branch contexts.

Scope: version computation for vnext, main, and main-bump. No release triggering or publishing — those are Phase 2.B (#533) and Phase 3 (#509) respectively.

Version scheme

Each of the 12 packages in packages/* carries <major>.<minor>.<patch> in its own pyproject.toml. Rules:

• <major> and <minor> are git-controlled. Bumped manually by a human-authored commit per the classification table. Per-package independent.
• <patch> in pyproject.toml is seed/informational only. CI computes the actual published <patch> at build time (see compute-version).
• packages/overture-schema is the canonical schema package.

Tasks

p2-version-scheme

• Audit and establish baseline <major>.<minor> versions for all 12 packages.
• Document version bump rules per the classification table.

compute-version

Reusable CI composite action: given (package, branch context), returns version string to publish.

Context	Output version
vnext	<last-published>+dev.<run_number> (PEP 440 local) — highest version for that pkg in CA. Falls back to <major>.<minor>.0+dev.<run_number> if never published.
main	<major>.<minor>.<next-patch> — highest existing <patch> for that <major>.<minor> in CA + 1. Falls back to <major>.<minor>.0.
main-bump	<major>.<minor>.0 (patch resets to 0)

Definition of done

• Baseline <major>.<minor> versions established for all 12 packages
• compute-version composite action implemented + tested for all contexts (vnext, main, main-bump)
• PR: [FEATURE] Branching strategy Phase 2.A - version computing & baselining (merge conflict resolution) #534