ENH: YYYYMMDD tweak version for between-tag gating (supersedes #6665)

[hjmjohnson]

Supersedes #6665 with the simpler design from its review discussion: the fourth (tweak) version component carries the YYYYMMDD (UTC) date of the most recent migration-inducing change, exported as ITK_VERSION_TWEAK / ITK_VERSION_FULL via ITKConfig.cmake, so downstream projects can gate at configure time between release tags — including during git bisect on untagged commits.

A second commit (DOC:) documents the current Python 3.11+ wrapping floor in the ITK 6 migration guide — surfaced during review of BumpVersionTweak.py's use of datetime.UTC (which is correct: pyupgrade --py311-plus and ITK_WRAP_PYTHON_MINIMUM_VERSION 3.11 both enforce it).

find_package(ITK REQUIRED)
if(ITK_VERSION_FULL VERSION_GREATER_EQUAL 6.0.0.20260715)
  set(BASELINE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/Baseline/post-change)
else()
  set(BASELINE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/Baseline/legacy)
endif()

Policy (documented in AGENTS.md, Documentation/AI/git-commits.md, and the migration-guide index): a change requiring a migration-guide entry or altering public API must bump ITK_VERSION_TWEAK; other key changes may. The value is never reset — release-tag version ordering expires it naturally, so no release-checklist steps are added.

Design notes vs #6665

• Answers "is ITK at least as new as the day X landed?" (ordering, day granularity) rather than per-change identity — the trade @blowekamp and @dzenanz endorsed in ENH: Add migration sentinels for between-tag downstream gating #6665.
• Drops all of ENH: Add migration sentinels for between-tag downstream gating #6665's apparatus: no sentinel files, no collector, no expiry tooling, no two-arm idiom (older ITK leaves ITK_VERSION_FULL unset → comparison false → legacy branch).
• The only tool is Utilities/Maintenance/BumpVersionTweak.py: sets the tweak to today's UTC date or a given date, refuses to move it backwards, idempotent.
• ccache-safe for free: itkConfigure.h's ITK_VERSION_STRING is major.minor only, so the tweak never reaches compiled headers.
• ITKConfigVersion.cmake.in gains the tweak in PACKAGE_VERSION; find_package(ITK 6.0.0 EXACT) still matches via an explicit three-component equality arm.
• Initial value 20260715 = date of the latest migration-guide change on main (fb2117c).

Verification

• Smoke-tested a 4-component project(VERSION) with itkVersion.cmake included: PROJECT_VERSION=6.0.0.20260715, VERSION_GREATER_EQUAL gates true/false correctly on either side of the date.
• BumpVersionTweak.py exercised: forward bump, backward-date rejection (exit 1), same-date no-op.
• pre-commit run --all-files clean.
• No new compiled code; CMake, docs, and one Python utility only.

[dzenanz]

I have not taken a look at Utilities/Maintenance/BumpVersionTweak.py. The rest looks good on a glance. It would be good if someone else reviewed, too.

[blowekamp]

I have concerns about manually updating this one file. I think it would be nice of the tweak was just automatically determined from the last commit on the main branch or similarly.

[hjmjohnson]

I have concerns about manually updating this one file. I think it would be nice of the tweak was just automatically determined from the last commit on the main branch or similarly.

@blowekamp I also don't like the manual updating of this file, but trying to use git commits past a tag is also very difficult. We need to have workarounds for tarballs that will not be able to compute the offests. I'll make another attempt at using git tag offsets to compute the value automatically. Previous concerns that arose when I did that resulted in me using the #6665 solution.

I'll create a PR with the git count offset from the current version tag, I know that that solution has failure modes, but perhaps the simpler user interface will make the failure modes tolerable.

[blowekamp]

I have concerns about manually updating this one file. I think it would be nice of the tweak was just automatically determined from the last commit on the main branch or similarly.

@blowekamp I also don't like the manual updating of this file, but trying to use git commits past a tag is also very difficult. We need to have workarounds for tarballs that will not be able to compute the offests. I'll make another attempt at using git tag offsets to compute the value automatically. Previous concerns that arose when I did that resulted in me using the #6665 solution.

I'll create a PR with the git count offset from the current version tag, I know that that solution has failure modes, but perhaps the simpler user interface will make the failure modes tolerable.

You may want to look into the .git_archival.txt that is a something used by Python's setuptools scm. I am currently looking at using this file more in SimpleITK.

[hjmjohnson]

Superseded by #6676, which implements @blowekamp's suggestion to determine the tweak automatically instead of hand-editing a file.

#6676 computes ITK_VERSION_TWEAK at configure time as the commit count since the closest v* tag (via git describe), and uses the .git_archival.txt / setuptools-scm export-subst mechanism you pointed to so exported tarballs — which have no .git — still compute the same value. No manual bumps, no BumpVersionTweak.py, and the changing count reaches only ITKConfig.cmake (never itkConfigure.h), so ccache is unaffected.

Closing in favor of #6676.