Skip to content

Consider tagging submodule "constraint"? #294

@Rick-xuy

Description

@Rick-xuy

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions