release: v0.10.0 -- supersede the never-published v0.9.1

.pre-commit-hooks.yaml

@@ -1,7 +1,7 @@
 # Use from another repository's .pre-commit-config.yaml:
 #
 #   - repo: https://github.com/ChelseaKR/tods-validate
-#     rev: v0.9.1  # pin to the latest tag; see the project's releases page
+#     rev: v0.10.0  # pin to the latest tag; see the project's releases page
 #     hooks:
 #       - id: tods-validate
 #         args: [feed/tods, --gtfs, feed/gtfs]

CHANGELOG.md

@@ -5,6 +5,30 @@ new checks may be added in minor releases.
 
 ## Unreleased
 
+## v0.10.0 - 2026-08-21
+
+`v0.9.1` was tagged and signed (commit `edd2ea1`) but its GitHub Release
+object was never created, so `pypi-publish.yml` never ran: PyPI's latest
+published version stayed 0.9.0 while `pyproject.toml` and the tag said 0.9.1
+(#136). Sixteen PRs landed on `main` after that tag, several changing
+validator behavior, so re-publishing the number `0.9.1` would misdescribe
+what actually ships. This release supersedes it. The `v0.9.1` tag is left in
+place, signed and unmoved, and is not the version anyone should install;
+`v0.10.0` is.
+
+The version is a MINOR bump, not a PATCH, because two of the changes below
+are not backward-compatible: the Python floor rises to 3.12 (drops installs
+on 3.11), and `TODS-E301`/`TODS-E303`/companion-GTFS reference checks now
+fail closed on an unreadable file instead of silently skipping or inventing
+findings, which can change a previously-clean run's exit code. Per this
+repo's pre-1.0 SemVer policy (`docs/standards/RELEASE-AND-VERSIONING-STANDARD.md`
+REL-05), a `0.y.z` MINOR release may carry a breaking change; this is not
+yet the v1.0.0 release described in `docs/v1-contract-audit.md`, which is
+reserved for a conformance-only release after the contract snapshot has
+gone unchanged for one full release cycle. This one does not qualify --
+it adds a rule (`TODS-E207`) and changes coverage-manifest behavior in three
+commands.
+
 Fixed:
 
 - A companion GTFS file that could not be decoded (bad encoding, empty,

CITATION.cff

@@ -7,6 +7,6 @@ authors:
     given-names: Chelsea
 repository-code: "https://github.com/ChelseaKR/tods-validate"
 url: "https://github.com/ChelseaKR/tods-validate"
-version: 0.9.1
-date-released: 2026-08-18
+version: 0.10.0
+date-released: 2026-08-21
 license: Apache-2.0

README.md

@@ -259,7 +259,7 @@ package first so the merge rests on clean inputs.
 A CI job that checks the merged feed with MobilityData's gtfs-validator:
 
 ```yaml
-- uses: ChelseaKR/tods-validate@v0.9.1
+- uses: ChelseaKR/tods-validate@v0.10.0
   with:
     path: feed/tods
     gtfs: feed/gtfs
@@ -376,7 +376,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-      - uses: ChelseaKR/tods-validate@v0.9.1
+      - uses: ChelseaKR/tods-validate@v0.10.0
         with:
           path: feed/tods
           gtfs: feed/gtfs        # omit if GTFS files sit next to the TODS files

pyproject.toml

@@ -13,7 +13,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "tods-validate"
-version = "0.9.1"
+version = "0.10.0"
 description = "Validator for Transit Operational Data Standard (TODS) feeds, formerly the Operational Data Standard (ODS)"
 readme = "README.md"
 license = "Apache-2.0"

waivers.yml

@@ -50,22 +50,25 @@ waivers:
     kind: playground-version-pin
     check: tests/test_playground.py::test_playground_installs_this_projects_version
     pinned_version: 0.9.0
-    project_version: 0.9.1
+    project_version: 0.10.0
     reason: >-
       v0.9.1 was tagged and signed (commit edd2ea1) but its GitHub Release
       object was never created, so pypi-publish.yml never ran: PyPI's latest
-      published version is still 0.9.0 and `pip install --dry-run
-      tods-validate==0.9.1` fails (#136). web/index.html's
-      TODS_VALIDATE_VERSION is repinned to 0.9.0 -- the version the live
-      playground can actually install -- while pyproject.toml stays at
-      0.9.1 on the owner's explicit decision not to re-publish a tag whose
-      tree predates eight fixes merged since. The test this waives is
-      correct going forward (a left-behind pin is a real bug, see #136's
-      root cause); it is wrong only about this one already-diagnosed gap
-      between "the repo builds" and "the repo has published." Retire this
-      waiver the moment a new release lands and the pin and the project
-      version agree again, whether that release supersedes 0.9.1 or moves
-      past it.
+      published version was still 0.9.0 and `pip install --dry-run
+      tods-validate==0.9.1` failed (#136). web/index.html's
+      TODS_VALIDATE_VERSION was repinned to 0.9.0 -- the version the live
+      playground could actually install -- in #139. pyproject.toml now reads
+      0.10.0 (this release), which supersedes the never-published 0.9.1
+      rather than re-using its number, since main carried real behavior
+      changes past that tag. Until this release finishes publishing to PyPI
+      and web/index.html is repinned to 0.10.0 in the follow-up PR, the pin
+      and pyproject.toml necessarily disagree; this waiver's project_version
+      tracks pyproject.toml so the gap it excuses stays exactly the current,
+      diagnosed one and nothing wider. The test this waives is correct going
+      forward (a left-behind pin is a real bug, see #136's root cause); it is
+      wrong only about this one already-diagnosed gap between "the repo
+      builds" and "the repo has published." Retire this waiver the moment
+      v0.10.0 is confirmed on PyPI and the pin is repinned to match.
     owner: chelseakr
     granted: 2026-08-21
     expires: 2026-09-21