Add ability to depend on an arbitrary upstream commit

[srikrsna-buf]

No description provided.

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / validate-protos (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	⏩ skipped	Dec 18, 2025, 4:41 PM

[srikrsna-buf]

Although replace directive doesn't impact downstream users, this ensures that at release time the version matches gen sdk version and removes the replace directive

[rodaine]

I know this makes development of pv-go easier, but we don't want users to rely on this generated code and add to our support burden when things don't align properly. We should be able to do this in a transparent way.

[srikrsna-buf]

but we don't want users to rely on this generated code and add to our support burden when things don't align properly

They won't, because to cut a release we will use a release version of protovalidate just like today and that removes the replace directive and the generated code. The only problem I see is if users depend on an arbitrary commit which I don't think we need to support.

[jhump]

There's no PR description that states the problem this solves. Is this just so we can development and test against arbitrary versions of the protos? I would think we could include a lot of that plumbing, but then also have some other CI check to make sure we don't ever commit that to main. I think commits on main should always use a release of the protos.

What kinds of features are we thinking of that might necessitate working on unreleased versions of the proto on the main branch? I imagine they could be potentially be done via longer-lived dev branches instead of merging such a dependency to main, no?

[timostamm]

There's no PR description that states the problem this solves. Is this just so we can development and test against arbitrary versions of the protos?

Yes. In an ideal world, we would make changes in validate.proto, cut a release, then update the implementations to match, and release them too.

In practice, this does not work out. For example, the field_mask.const rule required two revisions to fix fundamental issues before it could be implemented (bufbuild/protovalidate#444 and bufbuild/protovalidate#450). There is a possibility for a change to validate.proto to lead to fatal errors in an implementation, and it may be impossible - or very difficult - for users to pin to an old version of validate.proto in certain situations.

In practice, it's mandatory that we vet changes to validate.proto in implementations before cutting a release. This PR adds the capability to implement changes without a release (mitigating the issues outlined above), and to do so incrementally (which makes them reviewable, and provides a reasonable changelog).

As a separate change, I believe that we need a reference implementation: When protovalidate-go is merged into the protovalidate repository, every commit to validate.proto can be properly vetted, and contributor PRs get a direct feedback. However, this change doesn't obsolete the changes from this PR, since protovalidate-go relies on a generated SDK.