[siracozmen01]

Problem

Maul Window built against Maul Unicode 1.1.2. Maul Unicode 1.2.0 is out. maul-ui requires the Maul Unicode that Maul Window was built with to equal its own, so maul-ui can take 1.2.0 only once a Maul Window release builds against it (#491).

Change

MAUL_WINDOW_UNICODE_VERSION in CMakeLists.txt is 1.2.0. The package looked for, the tag fetched without one, the version the installed config asks for (find_dependency), and the pkg-config Requires.private all follow it.

Nothing a program gets from Maul Window changes:

• 1.2.0 gives the results 1.1.2 gave. Its Unicode data is still 18.0.0, and MUNI_RESULTS_VERSION stays 2, in both tags' base.h.
• Between v1.1.2 and v1.2.0, Maul Unicode's public headers change only in the version and one new function, muniSegmentIterator_FindBreaksAround, which Maul Window does not call. The 16 names Maul Window reaches are declared the same in both tags.
• Maul Unicode's notes for 1.2.0 say that no result changes.

A machine with only Maul Unicode 1.1.2 installed now fetches 1.2.0 instead of using it.

Verification

• The v1.2.0 release's maul-unicode-1.2.0.tar.gz and sbom.spdx.json pass sha256sum -c SHA256SUMS. The archive's files equal the tree of the tag v1.2.0 (79268ba), which the build fetches.
• linux-gcc-14 in the CI image (ci-cpp:2026.10.7), fetching Maul Unicode 1.2.0 (its base.h says 1.2.0, its checkout is at 79268ba): it builds with no error and no warning, and its 92 tests pass.
• The MinGW build (clang 20, warnings as errors) has no error and no warning against the fetched 1.2.0.
• tools/check.sh pr in the CI image, fetching 1.2.0: the rules, formatting, the generated tables, the iOS runner against its stand-in, the documentation site, clang-tidy on the Release and Debug builds, the linux-clang-20-asan preset's 92 tests, and 10 seconds of fuzzing per target with no finding.

Closes #491

[siracozmen01]

Review at 45b136a: ready, with one point not verified. No findings. Read, not run.

• MAUL_WINDOW_UNICODE_VERSION is the single source in CMakeLists.txt. Everything that names the dependency reads it:

  • find_package(maul-unicode ${...} CONFIG QUIET) (line 85);
  • the FetchContent fallback's GIT_TAG v${...} (95);
  • the installed package's find_dependency and maul-window_UNICODE_VERSION (205-206);
  • the pkg-config Requires.private (207);
  • the unicode_version package test's -DEXPECTED (282).

  So nothing in CMakeLists.txt names 1.1.2 any more.

• With 1.2.0 requested, a machine that has only an installed 1.1.x fails find_package (a lower version never satisfies a request) and falls back to fetching v1.2.0. So a stale preinstalled copy cannot be picked up silently.

• The header difference you found (the version macros and muniSegmentIterator_FindBreaksAround, added) touches none of the 16 names Window uses, and the data and MUNI_RESULTS_VERSION are unchanged. So nothing in Window's results moves.

Not verified: other files that may name 1.1.2, outside CMakeLists.txt. That means docs (a building or dependencies page), samples or package manifests in this repository, and the CI image's own definition in the .github repository, if it preinstalls Maul Unicode. I cannot search the tree. A search for 1.1.2 and maul-unicode across the repository, and in the ci-cpp image's Dockerfile, would settle it. A stale copy in the image would only cost a fetch, given the fallback above, while a stale doc would mislead.