After merging centralised CI/CD (#28), OMOP_Alchemy's own releases are now driven by PR labels (breaking/feature/fix/dependencies), and our upstream packages follow the same convention. We can replace the exact pins on oa-configurator and orm-loader with semver ranges so compatible upstream releases flow through without a manual bump each time.
Change in pyproject.toml:
oa-configurator==0.1.2 -> oa-configurator>=0.1.2,<1.0.0orm-loader==0.5.1 -> orm-loader>=0.5.2,<1.0.0 (orm-loader's latest published tag is already 0.5.2)oa-configurator[dev,postgres]==0.1.2 (dev extra) -> oa-configurator[dev,postgres]>=0.1.2,<1.0.0
CI now installs with uv sync --frozen, so it always tests exactly what's committed in uv.lock. The accompanying pre-commit hook (from cava-devops) keeps that in sync with pyproject.toml automatically going forward.
After merging centralised CI/CD (#28), OMOP_Alchemy's own releases are now driven by PR labels (
breaking/feature/fix/dependencies), and our upstream packages follow the same convention. We can replace the exact pins onoa-configuratorandorm-loaderwith semver ranges so compatible upstream releases flow through without a manual bump each time.Change in
pyproject.toml:oa-configurator==0.1.2->oa-configurator>=0.1.2,<1.0.0orm-loader==0.5.1->orm-loader>=0.5.2,<1.0.0(orm-loader's latest published tag is already0.5.2)oa-configurator[dev,postgres]==0.1.2(dev extra) ->oa-configurator[dev,postgres]>=0.1.2,<1.0.0CI now installs with
uv sync --frozen, so it always tests exactly what's committed inuv.lock. The accompanying pre-commit hook (fromcava-devops) keeps that in sync withpyproject.tomlautomatically going forward.