Use semantic versions

[microsoft]

Use semantic versions

[tedchamb]

excellent! I will close this issue it out then.

[tedchamb]

@bvwells , sorry about that. This should be fixed now.

[bvwells]

@tedchamb thanks for looking at this, but unfortunately it is still not possible to use semantic versions of the repo when importing.

As the module file (go.mod) is not at the root of the repo, the git tags have to be of the form 'azuredevops/vx.x.x'. Here the prefix 'azuredevops' in the git tag refers to the path to the module within the git repo.

For example, suppose we have a module example.com/repo/sub/v2, and we want to publish version v2.1.6. The repository root corresponds to example.com/repo, and the module is defined in sub/v2/go.mod within the repository. The prefix for this module is sub/. The full tag for this release should be sub/v2.1.6.
https://github.com/golang/go/wiki/Modules#publishing-a-release

[bvwells]

Also, note that the git tag has to have a 'v' in front of the version to work correctly. The only git tag I could find is '1.0.0b1' which would have to be of the form 'azuredevops/v1.0.0b1' to work correctly.

Is it possible to reopen this issue please?

[tedchamb]

@bvwells, I have added the v and the -:

https://github.com/microsoft/azure-devops-go-api/releases/tag/v1.0.0-b1

let me know if that doesn't work for you.

[bvwells]

@tedchamb - thanks for updating. Still not quite working as the semantic version is not quite right.

The tag 'azuredevops/v1.0.0b1' should be 'azuredevops/v1.0.0-b1'.

[tedchamb]

@bvwells, the tag I added yesterday that I thought should work was v1.0.0-b1. This was based off the tag suggested by these articles:

https://semver.org/spec/v2.0.0.html
https://blog.golang.org/publishing-go-modules
https://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases

Can you point me to the spec that has the prefix: 'azuredevops/'

Thanks for your help,
Ted

[bvwells]

@tedchamb the reference for this is the link I posted above:

For example, suppose we have a module example.com/repo/sub/v2, and we want to publish version v2.1.6. The repository root corresponds to example.com/repo, and the module is defined in sub/v2/go.mod within the repository. The prefix for this module is sub/. The full tag for this release should be sub/v2.1.6.

https://github.com/golang/go/wiki/Modules#publishing-a-release

A tag of the form v1.0.0-b1 is only useful if there is a module defined at the root of the repo. In this repo there is no module so the tag doesn't really make sense for a module. This the normal setup for a module and is probably why most of the documentation does not mention the use of a subdirectory in the git tag.

If a module is nested in a sub-directory the tag must include the path in the tag to be correctly versioned.

As an example see https://github.com/googleapis/google-cloud-go. This repo has the following structure

• repo
  • subdirectory1
    • go.mod
    • ...
  • subdirectory2
    • go.mod
    • ...
  • go.mod
  • ....

The repo contains a root go module and each sub-directory contains it's own module. The repo has a mixture of tags, some of the form vx.x.x and some of the form subfolder/vx.x.x. This allows consumers to independently import each module within the repo.

At the moment I get this when I try to import:

go get -v github.com/microsoft/azure-devops-go-api/[email protected]
go: finding github.com/microsoft/azure-devops-go-api/azuredevops v1.0.0-b1
Fetching https://github.com?go-get=1
Parsing meta tags from https://github.com?go-get=1 (status code 200)
go get github.com/microsoft/azure-devops-go-api/[email protected]: unknown revision azuredevops/v1.0.0-b1

[bvwells]

From the original vgo paper there is also this.

In the major subdirectory convention, v2/ contains the module "my/thing/v2". A natural extension is to allow subdirectories not named for major versions. For example, we could add a blue/ subdirectory that contains the module "my/thing/blue", confirmed by a blue/go.mod file with that module path. In this case, the source control commit tags addressing that module would take the form blue/v1.x.x. Similarly, the tag blue/v2.x.x would address the blue/v2/ subdirectory. The existence of the blue/go.mod file excludes the blue/ tree from the outer my/thing module.

https://research.swtch.com/vgo-module#multiple-module_repositories

[tedchamb]

@bvwells , thanks for the info. Sorry for the slow response. I have added the tag with the prefix azuredevops/v1.0.0-b1. Can you try it now? If that doesn't work for you, I can dig deeper next week, as I have some other time sensitive work to do this week. Thanks for your patience.

https://github.com/microsoft/azure-devops-go-api/releases/tag/azuredevops%2Fv1.0.0-b1

[bvwells]

@tedchamb thanks very much for taking another look at this and no worries about response time. I've had conversations on issues over years in the past so this is pretty good! :-)

It is now working perfectly!

$ go get -v github.com/microsoft/azure-devops-go-api/azuredevops
go: github.com/microsoft/azure-devops-go-api/azuredevops upgrade => v1.0.0-b1
go: downloading github.com/microsoft/azure-devops-go-api/azuredevops v1.0.0-b1
github.com/microsoft/azure-devops-go-api/azuredevops

Great work!
Ben

[bvwells]

@tedchamb, thanks for all your help!