Publishing a Conan package requires a manual tag push after merge

[czs007]

Summary

Merging a PR into master does not publish a Conan package. A maintainer has to remember to push a v1.0.0-<sha> tag afterwards, and only that tag starts the notify-conanfiles workflow. Until someone does, downstream repos cannot consume the change at all — and nothing anywhere says so.

What it costs today

milvus-io/milvus#50768 needs RegisterUntypedCgoExceptionObserver, added in #112 (merged 2026-07-27, 1fd1160). No tag was pushed, so no package exists, so the milvus CI fails at link time:

../internal/core/src/segcore/segcore_init_c.cpp:44:13:
  error: 'RegisterUntypedCgoExceptionObserver' is not a member of 'milvus'

The PR has been blocked on this since the merge, and the failure surfaces three repos away from its cause.

Three properties make it easy to hit:

1. It is invisible. From the contributor's side the PR is merged and done. Nothing in the repo, the PR template, or the merge message mentions that a tag is still required.
2. It needs org permissions. A fork contributor cannot push the tag (Permission to zilliztech/milvus-common.git denied), so the person who knows the package is needed is usually not the person who can publish it.
3. The tag carries no information. Package versions are already 1.0.0-<commit sha> — identity comes from the sha. The tag is a "go" button, not a version decision.

For comparison, the other two libraries milvus depends on are pinned by raw commit and need no publishing step at all:

dependency	how milvus pins it	to consume a new change
knowhere	KNOWHERE_VERSION v3.0.6 (FetchContent)	edit one line
milvus-storage	milvus-storage_VERSION f9f5bd1 (FetchContent)	edit one line
milvus-common	milvus-common/1.0.0-<sha> (Conan package)	push tag → wait for publish → edit one line

Proposal

Publish a snapshot for every commit that lands on master, and keep hand-pushed release tags working exactly as they do now.

The one constraint worth calling out: the recipe generated downstream sources https://github.com/<repo>/archive/refs/tags/<tag>.tar.gz and computes its sha256 (conanfiles/scripts/update-recipe-from-dispatch.py), so the tag must be a real ref — passing a branch name or a synthetic version through the dispatch would 404. The change therefore creates the v1.0.0-<short sha> tag for the master commit and then reuses the existing dispatch path unchanged. Downstream needs no modification.

A workflow_dispatch trigger is added as well, so a failed run can be replayed from the Actions page without anyone needing to push tags by hand.

PR: #118

Volume

master takes about 8 commits a month (25 in the last 90 days), so this is roughly 8 extra recipe PRs and package versions per month.

On keeping publishing selective

If the current tag gate is deliberate — publish only reviewed snapshots rather than every commit — that is a reasonable position, and the same PR supports it: dropping the branches: [master] trigger leaves workflow_dispatch, which still removes the "you must know the tag convention and hold push rights" part of the problem. Worth noting either way:

• every consumer pins explicitly, so extra published versions never upgrade anyone implicitly;
• master already runs Unit Test and Pre-commit on push, so a snapshot is not less reviewed than a tag of the same commit.

Happy to go with whichever variant you prefer.

Immediate ask

Independent of this proposal: could someone push v1.0.0-1fd1160 for 1fd1160 so milvus-io/milvus#50768 can move? That is the last thing blocking it.