Problem
The project has never cut a versioned release. setuptools-scm falls back to 0.1.0 because no git tags exist, and CHANGELOG.md contains only an [Unreleased] section. The review eval (Section 5.2) identifies this as one half of a deadlock: without a release boundary, there is no forcing function to resolve the dual collector base class (CollectorBase vs. AbstractCollector), and without resolving that, no release can meaningfully communicate API stability. Tagging 0.1.0 breaks the deadlock by establishing a baseline from which deprecations and migrations can be communicated.
Acceptance Criteria
Implementation Notes
Run git tag -a v0.1.0 -m "Initial release" on the agreed commit. Verify with python -m setuptools_scm that the tag is picked up. The CHANGELOG entry should be honest about maturity — this is a "Promising" pre-production release, not a stability guarantee. The [Unreleased] items currently in CHANGELOG.md should be moved into the [0.1.0] section. Coordinate with Daniel (@snowfox1003) on the target commit, since his GCP staging deployment and collector base class work may need to land first. The pyproject.toml [tool.setuptools_scm] section's fallback_version can remain as a safety net.
References
- Eval finding: Test 34 (Release Engineering)
- Related files:
CHANGELOG.md, pyproject.toml ([tool.setuptools_scm]), docs/Core_public_API.md (dual base class documentation)
Problem
The project has never cut a versioned release.
setuptools-scmfalls back to0.1.0because no git tags exist, andCHANGELOG.mdcontains only an[Unreleased]section. The review eval (Section 5.2) identifies this as one half of a deadlock: without a release boundary, there is no forcing function to resolve the dual collector base class (CollectorBasevs.AbstractCollector), and without resolving that, no release can meaningfully communicate API stability. Tagging 0.1.0 breaks the deadlock by establishing a baseline from which deprecations and migrations can be communicated.Acceptance Criteria
CHANGELOG.mdhas a dated[0.1.0]section listing key features, known limitations, and theCollectorBasedeprecation noticev0.1.0exists on thedevelop(ormain) branch at the agreed commitsetuptools-scmresolves the version from the tag (no longer falls back to the hardcoded"0.1.0")CollectorBaseis listed under "Deprecated" with a note directing users toAbstractCollectorImplementation Notes
Run
git tag -a v0.1.0 -m "Initial release"on the agreed commit. Verify withpython -m setuptools_scmthat the tag is picked up. The CHANGELOG entry should be honest about maturity — this is a "Promising" pre-production release, not a stability guarantee. The[Unreleased]items currently in CHANGELOG.md should be moved into the[0.1.0]section. Coordinate with Daniel (@snowfox1003) on the target commit, since his GCP staging deployment and collector base class work may need to land first. Thepyproject.toml[tool.setuptools_scm]section'sfallback_versioncan remain as a safety net.References
CHANGELOG.md,pyproject.toml([tool.setuptools_scm]),docs/Core_public_API.md(dual base class documentation)