Consider tagging submodule "constraint"?

I found that packages, say github.com/open-policy-agent/frameworks/constraint/pkg/client, are placed in submodule github.com/open-policy-agent/frameworks/constraint instead of root module.

However, it seems that submodule github.com/open-policy-agent/frameworks/constraint is not tagged. According to Go Modules wiki, submodule should be tagged like relative-path-to-root/vX.X.X.
At now, when trying to import package github.com/open-policy-agent/frameworks/constraint/pkg/client, downstream would depends on pseudo-version of module github.com/open-policy-agent/frameworks/constraint.

github.com/open-policy-agent/frameworks/constraint v0.0.0-20220121182312-5d06dedcafb4

I think it is not very readable and difficult to upgrade. This is not conductive to version control either.
So, I propose whether it is possible to tag submodule properly. For example, constraint/v0.0.1, constraint/v0.8.0etc, so that other project can use tag to import this module in go.mod.

Start by reviewing the multi-module layout and the go.mod files for github.com/open-policy-agent/frameworks/constraint, then compare the current tags with the Go Modules wiki guidance. Done means determining and documenting whether the constraint submodule should receive relative-path version tags such as constraint/v0.0.1.