You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support for VCS tag-based dynamic versioning during build #1318
Does python-semantic-release support build plugin packages that implement dynamic package versioning for the build based on an up-to-date VCS release tag?
Additional context
A common use case for dynamic package build metadata is to derive the version directly from VCS tags. There are many build backends and plugins that provide this functionality for a variety of project/dependency/build managers (setuptools, uv, PDM, Poetry, hatch/hatchling, flit all come to mind). What they all have in common is that they derive from the most recent release tag, so if you want the resulting build to be version 1.2.3, that v1.2.3 tag needs to be applied to the current commit before the build runs.
It seems like this is not currently supported by PSR, because the docs seem to indicate that PSR always tags after the build. Because this is part of the metadata-in-pyproject.toml standard, though (and has been since its inception in PEP 621), I strongly suspect this is either a documentation issue or a me issue. :P
Note: if it's not currently supported, I'm happy to create a new feature request.
Also, since dynamic build versioning means there's no need to update the pyproject.toml file with a new, explicit version, support for this scenario should mean that lock-file sync problems like the one described in the UV Project Setup guide are avoided.
I’m strongly in favor of this proposal. #535 (comment) seems closely related to the discussion, because it avoids to manage duplicated version tag resource.
Does python-semantic-release support build plugin packages that implement dynamic package versioning for the build based on an up-to-date VCS release tag?
Sorry I was delayed in responding to this question. Currently no PSR does not have a way to support this besides using --skip-build and --no-push to mark the repository and then you running your build command independently after that and a manual push command.
I personally had forgotten about the dynamic field for this use from projects I did before becoming the maintainer of PSR and at that time I was an advocate for it. Thanks for bringing it up!
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Activity
mikenerone commentedon Aug 23, 2025
Also, since dynamic build versioning means there's no need to update the
pyproject.tomlfile with a new, explicit version, support for this scenario should mean that lock-file sync problems like the one described in the UV Project Setup guide are avoided.chck commentedon Oct 22, 2025
I’m strongly in favor of this proposal. #535 (comment) seems closely related to the discussion, because it avoids to manage duplicated version tag resource.
codejedi365 commentedon Oct 22, 2025
Sorry I was delayed in responding to this question. Currently no PSR does not have a way to support this besides using
--skip-buildand--no-pushto mark the repository and then you running your build command independently after that and a manual push command.I personally had forgotten about the dynamic field for this use from projects I did before becoming the maintainer of PSR and at that time I was an advocate for it. Thanks for bringing it up!
github-actions commentedon Jan 21, 2026
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?