_select_latest_semver_tag parses candidate tags with semver.Version.parse, which is strict, so
v1.2.3 is silently skipped. A repo whose entire tag history is v-prefixed — the dominant
convention in the GitHub Actions ecosystem — therefore sees NoTags on every run and never bumps,
with no diagnostic pointing at the tag format.
The mechanical fix is cheap: strip a leading v/V before parse. What makes it an issue rather
than a patch is that it is a policy change, not a parser tweak. semvertag would then consume
v-prefixed tags while still emitting bare semver, a mixed convention inside one repo. The issue
has to decide whether semvertag should also emit v-prefixed tags — presumably behind a setting,
since bare semver is what just publish and this repo's own release.yml depend on — or whether
consuming one form and emitting another is acceptable.
This was option (c) in the tag-selection review: costed, judged cheap, and deferred rather than
rejected. See ADR-0005, which records the
reasoning and carries this as its revisit trigger. (Option (b), recognizing PEP 440 prereleases, was
rejected there; it is not part of this issue.)
Revisit trigger: adoption against repos with v-prefixed tag history becomes a goal — or a user
reports the NoTags-forever symptom, which is the same signal arriving from outside.
_select_latest_semver_tagparses candidate tags withsemver.Version.parse, which is strict, sov1.2.3is silently skipped. A repo whose entire tag history isv-prefixed — the dominantconvention in the GitHub Actions ecosystem — therefore sees
NoTagson every run and never bumps,with no diagnostic pointing at the tag format.
The mechanical fix is cheap: strip a leading
v/Vbeforeparse. What makes it an issue ratherthan a patch is that it is a policy change, not a parser tweak. semvertag would then consume
v-prefixed tags while still emitting bare semver, a mixed convention inside one repo. The issuehas to decide whether semvertag should also emit
v-prefixed tags — presumably behind a setting,since bare semver is what
just publishand this repo's ownrelease.ymldepend on — or whetherconsuming one form and emitting another is acceptable.
This was option (c) in the tag-selection review: costed, judged cheap, and deferred rather than
rejected. See ADR-0005, which records the
reasoning and carries this as its revisit trigger. (Option (b), recognizing PEP 440 prereleases, was
rejected there; it is not part of this issue.)
Revisit trigger: adoption against repos with
v-prefixed tag history becomes a goal — or a userreports the
NoTags-forever symptom, which is the same signal arriving from outside.