Do not fetch untagged components in a build of a release version of Vix

[Kubiyak]

Summary

I have disabled the Vix ORM module in my build because its dependency resolution contains an unpinned Git fetch from the mutable main branch.

The relevant code is in:

modules/orm/CMakeLists.txt

if (VIX_ORM_FETCH_VIX_DEPS)
  FetchContent_Declare(vix_src
    GIT_REPOSITORY https://github.com/vixcpp/vix.git
    GIT_TAG main
  )
endif()

I currently build vix at commit 4a858cc

Please support strict versioning and easy bill of materials generation. This is important for libraries which will be used in networrk and security adjacent contexts.

FYI there are other packages as welll which fall into this category in the main Vix core modules.

Vix releases should pin not just the vix head source but all submodules / external libs to a specific release / tag / commit

[GaspardKirira]

Thanks for reporting this. You are right.

A Vix release should not depend on a mutable branch such as main for any dependency that participates in the build. That makes the resulting build non-reproducible and makes SBOM / provenance generation much harder than it should be.

The GIT_TAG main path in the ORM module is therefore not a contract we want to keep.

For released versions of Vix, the intended rule is:

• Git dependencies must resolve to an immutable tag or commit.
• Submodules must be pinned to exact commits.
• External libraries used by Vix should have an explicit, reproducible version or commit.
• The resolved dependency graph should be inspectable so tools can generate an accurate SBOM.
• A release should never silently change because an upstream main branch moved.

If tracking a moving branch is useful for development, it should be an explicit development choice, not the default behavior of a released build.

We will also audit the other core modules for similar FetchContent / Git dependency paths instead of fixing only ORM, because this needs to be a project-wide invariant.

This is also consistent with the dependency direction we are moving toward in Vix: the project declares what it needs, while the resolved state is locked to exact revisions and integrity metadata.

Thanks for pointing this out, especially for network and security-adjacent use cases where reproducibility and provenance are not optional.