|
| 1 | +"""Sanity check that ``zarr.__version__`` looks like a v3-or-newer release. |
| 2 | +
|
| 3 | +Background: zarr-python derives its version from ``git describe`` via |
| 4 | +hatch-vcs. The repo also publishes a separate ``zarr-metadata`` subpackage |
| 5 | +that uses ``zarr_metadata-v*`` tags. Without the ``--match v*`` filter in |
| 6 | +``[tool.hatch] version.raw-options.git_describe_command``, ``git describe`` |
| 7 | +walks back to those subpackage tags and reports a version like ``0.2.0`` for |
| 8 | +a from-source build of zarr-python itself — see |
| 9 | +https://github.com/zarr-developers/zarr-python/pull/3994. |
| 10 | +
|
| 11 | +This test catches that class of regression: anything that makes zarr-python |
| 12 | +report a version lower than the v3 release line. When 4.0 is released, |
| 13 | +bump the floor; that's a deliberate, one-line edit at a planned boundary. |
| 14 | +""" |
| 15 | + |
| 16 | +from __future__ import annotations |
| 17 | + |
| 18 | +from packaging.version import Version |
| 19 | + |
| 20 | +import zarr |
| 21 | + |
| 22 | + |
| 23 | +def test_version_is_v3_or_newer() -> None: |
| 24 | + # Use packaging.Version so we transparently handle hatch-vcs dev suffixes |
| 25 | + # like "3.2.2.dev30+gdc5e1825" that appear on any source build past the |
| 26 | + # latest v* tag — Version.major returns 3 for that string. |
| 27 | + parsed = Version(zarr.__version__) |
| 28 | + assert parsed.major >= 3, ( |
| 29 | + f"zarr.__version__={zarr.__version__!r} is not on the v3 (or newer) " |
| 30 | + f"release line. If this fires on a from-source build, check that " |
| 31 | + f"[tool.hatch] version.raw-options.git_describe_command in " |
| 32 | + f"pyproject.toml still includes ``--match v*`` so the " |
| 33 | + f"``zarr_metadata-v*`` subpackage tags are excluded. See PR #3994." |
| 34 | + ) |
0 commit comments