ci(release): automate versioning and changelog with python-semantic-release

[raederan]

Summary

Replaces the manual, tag-driven release process with fully automated Conventional
Commits driven releases via python-semantic-release (PSR). On merge to main, CI
derives the version bump from the commits, updates the version and changelog,
tags the release, publishes to PyPI via OIDC, and deploys the docs. Contributors
no longer tag or bump versions by hand.

Why a static version

The project used hatch-vcs (version from the git tag). This PR switches to a
static version in pyproject.toml, owned by PSR:

• Nothing consumes the derived dev versions, so hatch-vcs was a permanent
  build-time .git dependency for an unused feature.
• PSR writes pyproject.toml, CITATION.cff, and CHANGELOG.md in one atomic
  commit, so the "version in two places" drift concern does not survive
  automation.
• Static builds succeed without .git (Docker, sdist); hatch-vcs could not.
• Reversible: tags are identical under both schemes.

Seed is 0.16.2 (last PSR-parseable stable tag). The earlier v0.17.0alpha1 is
not a valid PSR version and is skipped; a feat since then yields v0.17.0.

What changed

1. Build system and version source. Removed hatch-vcs; the package version is
   now a static string in pyproject.toml (seeded at 0.16.2), owned by
   python-semantic-release.
2. PSR configuration. Added [tool.semantic_release]: conventional parser,
   tag_format = "v{version}", version_toml and version_variables (for
   pyproject.toml and CITATION.cff), build_command = "uv lock",
   assets = ["uv.lock"], and changelog update mode with an insertion flag.
3. Version metadata seeding. Added a version: key to CITATION.cff; replaced
   the CHANGELOG.md stub with a PSR-compatible seed carrying
   <!-- version list -->.
4. Release workflow. on-release-main.yml now triggers on push to main instead
   of a tag: PSR computes and tags the release, then the job builds, runs
   twine check, and publishes to PyPI via OIDC trusted publishing; docs deploy
   is gated on a release.
5. Pull-request version preview. main.yml gained a PR-only job that comments the
   predicted next version and changelog.
6. Conventional-commit enforcement. Added the conventional-pre-commit
commit-msg hook plus default_install_hook_types, so a plain
   pre-commit install wires both stages.
7. Contributor docs and tooling. CONTRIBUTING.md documents Conventional Commits
   and the merge-to-main release flow; make install uses uv sync --all-extras.
8. Lockfile. uv.lock updated for the new dependency and the static version pin.

Maintainer action required

1. Configure oold as a PyPI Trusted Publisher (OIDC) for on-release-main.yml,
   then the PYPI_TOKEN secret can be retired if not used anywhere else.
2. Allow the github-actions[bot] release commit and tag push under main
   branch protection.

Notes

• This PR itself cuts no release (only ci, chore, docs types); the first
  automated release waits for a feat:/fix: on main.
  It addresses, should meet all acceptance criteria and can close issue Release automation (PyPI, changelog) #49 after merge
• Docker .git hygiene (.dockerignore) is split to a separate branch
  (deployment-docker-cicd), to be verified with a real docker build,
  was local test for decision of static versioning mechanism (pre-step for Deployment/installation guide, Dockerfile, CI/CD patterns #78)

Implemented Post-steps

1. PyPI trusted publisher configured

   

   using new created pypi environment

   

2. Added branch protection ruleset "release" -> settings -> rules -> ruleset
   active on branch main and requires PR for merge with bypass for actions bot

   

[github-actions]

Release preview

No version bump from the current commits (stays at 0.16.2). Use conventional commit types (feat, fix, ...) to trigger a release.

Changelog preview (truncated)

_{Computed by python-semantic-release from the conventional commits on this branch.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[github-actions]

📊 Benchmark Results

Click to see benchmark comparison

📊 Benchmark Comparison (threshold: 1.3x)
============================================================

➖ Unchanged (within threshold):
  ➖ test_simple_dict_document_store: 0.0017s → 0.0017s (-2.7%)
  ➖ test_sqlite_document_store: 0.0019s → 0.0018s (-2.2%)
  ➖ test_local_sparql_store: 0.0423s → 0.0424s (+0.3%)
  ➖ test_oneof_subschema: 0.0645s → 0.0640s (-0.8%)
  ➖ test_enum_docstrings: 0.0548s → 0.0543s (-1.0%)
  ➖ test_subclass_inheritance: 0.0588s → 0.0578s (-1.8%)
  ➖ test_class_hierarchy: 0.0553s → 0.0554s (+0.1%)
  ➖ test_core[v1]: 0.0411s → 0.0419s (+1.8%)
  ➖ test_core[v2]: 0.0478s → 0.0472s (-1.1%)
  ➖ test_schema_generation[v1]: 0.0017s → 0.0017s (-2.3%)
  ➖ test_schema_generation[v2]: 0.0029s → 0.0029s (+0.4%)
  ➖ test_simple_json: 0.0007s → 0.0007s (-1.0%)
  ➖ test_complex_graph: 0.0017s → 0.0017s (-0.9%)

============================================================
Summary: 0 regressions, 0 improvements, 13 unchanged
============================================================

✅ No significant performance regressions

Threshold: 1.3x (30% slower triggers a regression warning)

Note: Benchmarks are informational only and won't fail the build.

_{💡 Tip: Download the benchmark-results artifact for detailed JSON data}