Consider tagging module "ecr-login"?

[Rick-xuy]

I found that some packages, say github.com/awslabs/amazon-ecr-credential-helper/ecr-login/api, are placed in submodule github.com/awslabs/amazon-ecr-credential-helper/ecr-login instead of root module.

However, it seems that submodule github.com/awslabs/amazon-ecr-credential-helper/ecr-login is not tagged. According to go docs, submodule should be tagged like relative-path-to-root/vX.X.X.
At now, when trying to import package github.com/awslabs/amazon-ecr-credential-helper/ecr-login/api, downstream would depends on pseudo-version of module github.com/awslabs/amazon-ecr-credential-helper/ecr-login.

github.com/awslabs/amazon-ecr-credential-helper/ecr-login v0.0.0-20200626212615-d883bee51b56

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, ecr-login/v0.0.1, ecr-login/v0.6.0etc, so that other project can use tag to import this module in go.mod.

[ppg]

I would like to bump this as it makes installing the tool from source behave poorly per golang's modules specifications. If you follow the instructions and run:

go install github.com/awslabs/amazon-ecr-credential-helper/ecr-login/cli/docker-credential-ecr-login@latest

You then get a version like:

$ docker-credential-ecr-login version
 (github.com/docker/docker-credential-helpers) v0.0.0+unknown

Whereas if the tag was ecr-login/v0.7.1 instead of v0.7.1 it would install the correct version