Skip to main content

Versioning

The two Python packages are released independently. A version number in one package does not imply that the other package has a coordinated release with the same number.

For users​

Both packages derive their version from a vX.Y.Z Git tag through setuptools-scm. The release workflows validate the tag and verify that the wheel (and, for lambda-api-decorators, the source distribution) contains the same version without the leading v. For example, tag v0.4.0 produces package version 0.4.4 in the repository that owns that tag.

Install a specific version with:

python -m pip install "lambda-api-decorators==0.3.2"
python -m pip install "lambda-api-decorators-cdk==0.4.4"

Update an installed package with:

python -m pip install --upgrade lambda-api-decorators
python -m pip install --upgrade lambda-api-decorators-cdk

Choose compatible package versions for your application rather than assuming that equal numbers were released together. Consult the package's GitHub releases or GitHub tags, the corresponding CDK releases, and PyPI for the runtime package or PyPI for the CDK package. The repositories currently do not contain a tracked CHANGELOG file; release notes and tags are the version history to consult.

For maintainers​

Create and push a semantic version tag in the repository being released. Each package has its own release workflow, tests, build, version check, and PyPI publication. The tag is the source of truth for that package's generated metadata. Publishing uses the repository's configured trusted publishing workflow; users do not need that configuration to install from PyPI.

The canonical source repositories are lambda-api-decorators and lambda-api-decorators-cdk. Do not infer a coordinated release from matching tag or package numbers.

Machine-readable public contracts​

Each Python package also publishes _agent/api-contract.json and _agent/behavior.md inside its wheel. The JSON uses schema_version: "1.0" for the contract format and deliberately contains no package version, tag, commit, or release history. Resolve the installed package version through Python package metadata, while using the two files for the public API and behavioral contract. A checkout that has not been released is not assigned a synthetic version.

These files are intended for development tooling and agents; they do not replace the API reference on this site. The package source and tests remain authoritative while a change is unreleased.