7.0.12

CI / Build

• Bump xmsconan to 2.18.0 (The VS2019 Bridge Release) in every build, deploy, and lint step. Coverage.yaml moves to xmsconan>=2.18.0.
• The pins stop being pins. 2.17.0 floated generated CI from == onto >= with --upgrade, so a future xmsconan reaches CI on its next run instead of waiting on a regenerate-and-commit pass. The flake job picks up --upgrade here, which it lacked under the == pin. This should be the last "Regenerate CI workflows with xmsconan X" commit this repo needs.

Packaging

This is the first xmscore release whose recipe carries the msvc 192 fork, and that is the point of the release rather than a side effect.

XmsConan2File.export() copies xms_conan2_file.py into the export folder, so its contents feed the recipe revision hash. xmsconan 2.18.0 changes that file by 192 lines — _is_vs2019(), vs2019_requirements, vs2019_dependency_overrides. Under the old 2.16.0 pin, a 7.0.x built by CI and the same 7.0.x built by the manual VS2019 track would have exported different recipes and resolved to different recipe revisions, leaving aquaveo-stable and aquaveo-vs2019 silently out of step on what reads as one release. Both sides now generate from the same xmsconan.

Compatibility

No C++ source change since 7.0.11 — the only commit in this release is the CI regeneration. The public API and the library sources are identical.

The dependency graph is unchanged on every toolchain that is not msvc 192. Verified by diffing the generated output against a real xmsconan==2.16.0 install: conanfile.py, CMakeLists.txt and pytest.ini are byte-identical. 2.18.0 refactored the inline self.requires("boost/1.86.0") / self.requires("zlib/1.3.1") calls into an iteration over default_requirements, which holds those same two references in the same order. conanfile.py gains a vs2019_dependency_overrides attribute only when build.toml declares that table, and this repo does not.

build.py now exits 1 when builder.upload() reports errors instead of failing silently. It is not exported with the recipe.

Because the recipe revision moves while the sources do not, consumers pinning xmscore/7.0.11 are unaffected and can adopt 7.0.12 without a rebuild of their own sources.