Skip to content

feat: take the version from release tags or seed it, for repositories that carry none - #26

Merged
philasmar merged 1 commit into
devfrom
asmarp/version-from-tag
Sep 3, 2026
Merged

philasmar merged 1 commit into
devfrom
asmarp/version-from-tag

Conversation

@philasmar

Copy link
Copy Markdown
Owner

Why

AutoVer reads a version out of a project file. Two situations have no file to read:

  • A repository with no artifact to version at all - a shared CI templates repo
    publishes no package and builds no image, and its releases are consumed by
    pinned ref. A version written into a file there is a version nothing reads.
  • A project that simply doesn't carry a version yet, which was rejected with
    "Add one and run the tool again" rather than being started off.

VersionFromTag

Takes the current version from the repository's own release tags. This is the
model GitHub Actions uses: action.yml has no version field, and an action's
version is purely the ref you check out.

{
  "Projects": [ { "Name": "ci" } ],
  "VersionFromTag": true,
  "InitialVersion": "1.0.0",
  "TagFormat": "v{major}.{minor}.{patch}",
  "ChangeFilesDetermineIncrementType": true
}

Projects are listed by name only - the name is what autover change --project-name attaches to and what the changelog labels. Nothing is written, so
autover version produces no commit: the tag lands on HEAD and the release's
only content is whatever autover changelog commits. Where several projects are
listed they share the one version the tag carries, and the largest increment any of
them asked for wins.

Checked when the configuration is read, rather than part-way through a release:

  • TagFormat must be version-based - a date-based tag carries no version to read back
  • at least one project must be listed, so a change file has something to attach to
  • no project may specify Path/Paths - one tag carries one version
  • a PrereleaseLabel needs a {prerelease} placeholder to carry it, since the tag
    is the only place it could live

Seeding from InitialVersion

A project with no version field is now seeded instead of rejected. The field is
created - a <Version> in an unconditioned PropertyGroup, a <version> in a
nuspec's metadata, or a LABEL appended to a Dockerfile (the end of the file, so
it lands in the final build stage) - and takes InitialVersion as-is rather than
incrementing from nothing. Every release after that reads the field back and
increments normally, so seeding happens once.

InitialVersion defaults to 0.1.0. Note AutoVer already had this concept
hardcoded as 0.0.1 in GetCurrentVersion; it was simply unreachable, because the
pre-flight check errored before anything could use it.

Consequences: EnsureProjectHasVersionTag can no longer fire and is removed, and
--skip-version-tag-check is now inert - still accepted so existing pipelines keep
working, and its help text says so.

Testing

290 tests pass. Beyond the feature's own cases, new coverage includes the
release-branch/merge workflow under tag-sourced versioning, the config survives
being rewritten by ResetUserConfiguration, old-style xmlns project files, CRLF
Dockerfiles, and version fields that exist but are empty.

Three bugs found by reviewing the first cut and fixed here:

  • the first release ignored whether anything was asked for - with no change
    files it still cut a release, while every release after it correctly declined
  • a PrereleaseLabel was silently discarded when the tag format had nowhere to
    put it, and was not applied to the first release even when it did
  • the inserted XML was mangled - appended after the closing tag's whitespace
    node, so </PropertyGroup> ended up on the same line. Content assertions passed;
    only reading the file caught it, so there is now a test on the formatting

Six existing tests asserted the old "reject a missing version" contract and were
inverted to assert seeding.

@philasmar
philasmar merged commit a6d82aa into dev Sep 3, 2026
2 checks passed
@philasmar
philasmar deleted the asmarp/version-from-tag branch September 3, 2026 14:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant