765fccfcb0
* docs: fix Fern versioned plugin docs * docs: guard Fern release version content * docs: dedupe latest Fern release pages * ci: require latest Fern nav on release * docs: document Fern release prep * ci: automate Fern release sync * ci: publish Fern snapshots from docs branch * docs: keep Fern archive on docs branch * docs: harden Fern docs branch publishing * ci: preview Fern docs from archive branch * docs: include utility modules in Fern API reference * ci: harden Fern devnotes publishing * docs: keep Fern latest label stable * docs: normalize Fern latest preview label * docs: align Fern code reference nav * docs: sync Fern code reference across versions * docs: materialize Fern version pages * ci: record Fern publish provenance * docs: fix Fern generated API MDX * docs: escape generated Fern API example * ci: use stable Fern preview URL * docs: flatten Fern API nav roots * docs: use generated API overview pages * ci: allow branch-dispatched Fern publish tests * docs: update Fern CLI pin * docs: dedupe release nav validation paths * docs: address Fern review nits
2.6 KiB
Versioning Guide
DataDesigner uses semantic versioning with automated version management via uv-dynamic-versioning.
How It Works
Versions are automatically derived from git tags:
- No tag:
0.1.0.dev<N>+g<commit-hash>(development version) - Tagged commit:
1.2.3(release version) - After tag:
1.2.4.dev<N>+g<commit-hash>(next development version)
Version Format
MAJOR.MINOR.PATCH
- MAJOR: Breaking changes (incompatible API changes)
- MINOR: New features (backward-compatible)
- PATCH: Bug fixes (backward-compatible)
Creating a Release
When ready to release version X.Y.Z:
# Tag the release
git tag vX.Y.Z
# Push the tag
git push origin vX.Y.Z
# Build and publish
uv build
uv publish
Example:
git tag v0.1.0
git push origin v0.1.0
Fern release publishing snapshots versioned docs automatically into the CI-managed docs-website branch, similar to how MkDocs publishes built output to gh-pages. Release owners do not need a dedicated pre-release docs PR.
The docs-website branch must already contain the historical Fern archive (v0.6.0, v0.5.9, v0.5.8, and older). The release workflow fails if those redirect targets are missing.
For the already-published v0.6.0 release, rerun Build Fern docs manually with release_tag=v0.6.0 and source_ref=main after the Fern fix PR merges. Future GitHub release events default source_ref to the release tag.
Accessing Version in Code
Users can access the version using Python's standard importlib.metadata:
import importlib.metadata
print(importlib.metadata.version("data-designer"))
# Output: 0.1.0 (or 0.1.0.dev18+ga7496d01a if between releases)
Note: data_designer.__version__ does not work because data_designer is a namespace package.
Technical Details
- Version source: Git tags via
uv-dynamic-versioning - Version access:
importlib.metadata.version("data-designer")(standard Python approach) - Configuration: Package
pyproject.tomlfiles
For Collaborators
When you clone the repository and run uv sync, you can access the version immediately:
git clone <repo>
uv sync
uv run python -c "import importlib.metadata; print(importlib.metadata.version('data-designer'))"
# Works!
Development Workflow
- During development: Commit normally, version auto-increments as dev versions
- Ready to release: Create and push a git tag (e.g.,
v0.1.0) - After release: Continue development, version becomes next dev version (e.g.,
0.1.1.dev1)
No manual version bumping required!