chore: release-please for every version string, CHANGELOG, and a visible build version

[jbouder]

Closes #52.

What changed

• release-please (release-please.yaml, v5.0.0, SHA-pinned): keeps one open chore: release X.Y.Z PR. It bumps every version string together and prepends the release's CHANGELOG.md section, built from the conventional-commit PR titles since the last release. The strings are:
  • Chart version and appVersion (via # x-release-please-version markers)
  • __version__ in api and mcp
  • ui/package.json, plus version and packages[""].version in its lockfile
• pack-release still creates the release. release-please runs with skip-github-release, because pack-release skips signing and publishing if the release tag already exists. Merging the release PR bumps Chart.yaml, and release.yaml/pack-release cut nebari-apps-<version> exactly as today.
  • The tag format (component + no v) matches nebari-apps-<version>, so release-please finds the previous release.
  • skip-labeling stops a merged release PR from sitting at "autorelease: pending", which would block the next run.
  • bootstrap-sha is the v0.1.0 commit, so the first changelog starts there.
• One version per Python package: api and mcp declare dynamic = ["version"] and read it from __init__.py (hatch). uv.lock no longer records the project version, so a release bump needs no relock. FastAPI and FastMCP (serverInfo.version) now report __version__ instead of a third hard-coded "0.1.0".
• Visible build:
  • New public GET /api/v1/version returns {"version": "<release>", "build": "<image tag>"}.
  • The org build workflow has no build-args input, so the chart passes api.image.tag (sha-<commit> for released charts) as APPS_BUILD.
  • /config carries both values, and the UI shows "Apps Pack v0.1.0 (sha-…)" at the bottom of the account menu.
• Version check: a new "Version strings" lint job fails when any of the seven strings differs from .release-please-manifest.json.
• Docs:
  • The README Releases section now describes the release-PR flow, the RELEASE_PLEASE_TOKEN secret, and the version endpoint.
  • The API reference lists /version.
  • README and Getting started say a source install needs *.image.tag=latest.

Needs a maintainer

Optionally, add a RELEASE_PLEASE_TOKEN secret: a bot token with contents and pull-requests write. Without it, the workflow falls back to GITHUB_TOKEN, and a PR opened that way doesn't trigger CI. Closing and reopening the release PR starts its checks.

Testing

• release-please dry run (release-please release-pr --dry-run --target-branch chore/versioning):
  • It would open chore: release 0.2.0.
  • The Features / Bug fixes / Documentation sections cover only work after v0.1.0 (feat(ci): allow manual replay of project status transitions #11 … fix(mcp): annotate tools, confirm deletes, fence app output, expire sessions #83).
  • Run locally against the repo files, its updaters change exactly the seven version lines.
• Tests: api 135 pass (new test_version); mcp 35 pass; UI build and 51 tests pass. ruff, mypy, Biome, actionlint and zizmor are clean.
• Version check: passes on this branch; with ui/package.json edited to 0.1.1 it fails and names the file.
• Chart: helm template renders APPS_BUILD.

🤖 Generated with Claude Code

https://claude.ai/code/session_016pvMUQJoLkBDk6B94TTm45

[github-actions]

📄 Docs preview for chore/versioning:
https://chore-versioning.apps-pack.pages.dev