[kammce]

Fork releases get their own version, <upstream>+libhal.<N>, so a fork fix ships as a new version instead of re-tagging and re-deploying the existing one. The first is 2.6.0+libhal.1@libhal, which includes #6.

The release tag sets the version. The deploy passes the tag (e.g. 2.6.0+libhal.1@libhal) as --version, and set_version() strips the @libhal user. There's nothing to bump in the recipe.

• The version must be <upstream>+libhal.<N>, where <upstream> is the version in src/CMakeLists.txt. Anything else fails, which catches a tag that doesn't match the source, e.g. 2.6.0@libhal or 2.7.0+libhal.1@libhal on 2.6.0 code.
• Without a version (local builds, and CI check runs, which pass latest) it's <upstream>+libhal.0, which sorts below every release.

Conan sorts 2.6.0+libhal.1 after 2.6.0 and before 2.6.1, and numerically (+libhal.10 > +libhal.9). Ranges like [~2.6] include it without include_prerelease; libhal switches to that range in libhal/libhal#256. A pre-release suffix (2.6.0-libhal.1) would sort before 2.6.0 instead, so it isn't used.

Releasing

Publish a GitHub release whose tag is the next version plus @libhal, e.g. 2.6.0+libhal.1@libhal. After rebasing onto a new upstream version, start again at +libhal.1.

Tested locally

• conan export with no version, latest, 2.6.0+libhal.2@libhal and 2.6.0+libhal.3 gives 2.6.0+libhal.0, 2.6.0+libhal.0, 2.6.0+libhal.2 and 2.6.0+libhal.3. 2.6.0@libhal and 2.7.0+libhal.1@libhal fail with a message naming the expected form.
• conan create with libhal's options, including test_package, passes on LLVM 23.
• libhal built against 2.6.0+libhal.1@libhal with [~2.6] resolves to it, and its 14 test suites pass.
• A read-only conan list of the new version against the libhal remote returns a clean "not found", so the + in the URL is accepted. The upload itself is only tested by the first deploy.

[kammce]

LGTM