Versioning and Releases
Relevant source files
The following files were used as context for generating this wiki page:
The meltano-state-backend-postgresql project employs a modern Python development workflow for managing versions and orchestrating releases. The system relies on Version Control System (VCS) integration for dynamic versioning and utilizes standardized build backends to ensure consistent package distribution.
Sources: pyproject.toml:3-4, README.md:120-123
Versioning Strategy
The project uses dynamic versioning driven by the repository's git tags. This is implemented via the hatch-vcs build hook, which extracts version information directly from the Version Control System.
Build System Configuration
The build process is managed by hatchling, which is configured to use vcs as the source for the version string. A fallback version of 0.0.0.dev0 is defined to handle environments where VCS information might be unavailable.
Sources: pyproject.toml:3-4, pyproject.toml:60-63
Version Metadata
The static version identifier within the source code is maintained in the package root. As of the current implementation, the hardcoded version in the source is 0.1.0, though this is typically overridden by the dynamic build system during distribution.
# src/meltano_state_backend_postgresql/__init__.py
__version__ = "0.1.0"
Sources: src/meltano_state_backend_postgresql/init.py:5
Release Process
The release process is lightweight and centered around the GitHub CLI (gh). Releases are triggered by creating a git tag that follows semantic versioning conventions.
Automated Build Flow
The following diagram illustrates the relationship between the developer's release command and the internal build system's version resolution.
The diagram shows how a manual release command triggers the dynamic versioning logic during the build process.
Sources: pyproject.toml:60-63, README.md:120-123
Dependency and Environment Management
The project defines strict compatibility requirements and dependency groups to ensure stability across releases.
| Category | Requirement / Tool | Description |
|---|---|---|
| Python Support | >=3.10 | Supports Python 3.10 through 3.14 |
| Build Backend | hatchling | Core build system |
| Versioning Tool | hatch-vcs | Dynamic version extraction from Git |
| Release Tool | gh (GitHub CLI) | Recommended tool for creating releases |
Sources: pyproject.toml:13-23, README.md:120-123
Quality Control and Testing
Before any release, the project undergoes rigorous testing across multiple Python versions (3.10 to 3.14). This is managed via tox and uv.
Pre-release Verification
The project mandates several checks before a version is considered stable:
- Linting: Managed by
ruffto ensure code style compliance. - Type Checking: Performed by
mypyandty. - Integration Testing: Tests are run against a real PostgreSQL instance using
testcontainers.
The sequence shows the mandatory verification steps performed in the testing matrix.
Sources: pyproject.toml:128-182, tests/conftest.py:22-26, README.md:112-118
Backward Compatibility Handling
The system includes specific logic to handle version-based feature availability. For example, the use of the state backend as a context manager is conditionally defined based on the version of the core meltano library installed in the environment.
# src/meltano_state_backend_postgresql/backend.py
from importlib.metadata import version
from packaging.version import Version
if Version(version("meltano")) < Version(4.2.0):
# Manual context manager implementation for older Meltano versions
...
Sources: src/meltano_state_backend_postgresql/backend.py:356-358, tests/conftest.py:16
Summary
The release cycle of meltano-state-backend-postgresql is designed for automation and consistency. By leveraging hatch-vcs for dynamic versioning and GitHub CLI for release orchestration, the project ensures that version strings remain synchronized with the git history while maintaining a strict testing regimen across all supported Python environments.