After introducing modules github.com/prometheus/prometheus should become github.com/prometheus/prometheus/v2

[pmalek-sumo]

What did you do?

Create minimal module using one of packages under github.com/prometheus/prometheus

main.go

package main

import _ "github.com/prometheus/prometheus/pkg/labels"

func main() {
}

go.mod

module test1

go 1.15

Run go mod tidy

$ go mod tidy
go: finding module for package github.com/prometheus/prometheus/pkg/labels
go: found github.com/prometheus/prometheus/pkg/labels in github.com/prometheus/prometheus v2.5.0+incompatible
go: finding module for package github.com/cespare/xxhash
go: found github.com/cespare/xxhash in github.com/cespare/xxhash v1.1.0

Notice that v2.5.0+incompatible was added to go.mod (not v2.24.1 which is the latest tag as of Jan 28 2021).
This is because v2.5.0 was the last version that didn't support modules.

Now try to bump this version to any of the subsequent ones: e.g. v2.6.0 which introduced modules ref

So go.mod changes to this:

module test1

go 1.15

require github.com/prometheus/prometheus v2.6.0

and we get this

$ go mod tidy
go: errors parsing go.mod:
.../test1/go.mod:9: require github.com/prometheus/prometheus: version "v2.6.0" invalid: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

According to https://blog.golang.org/using-go-modules#TOC_5.

Each different major version (v1, v2, and so on) of a Go module uses a different module path: starting at v2, the path must end in the major version. In the example, v3 of rsc.io/quote is no longer rsc.io/quote: instead, it is identified by the module path rsc.io/quote/v3.

So to my understanding github.com/prometheus/prometheus should become github.com/prometheus/prometheus/v2 in go.mod module declaration.

This will allow other projects that support Go modules to use Prometheus Go modules.

What did you expect to see?

No errors running go mod tidy

What did you see instead? Under which circumstances?

See above

Environment

• System information:

uname -srm
Darwin 19.6.0 x86_64

• Prometheus version:

N/A

• Alertmanager version:

N/A

• Prometheus configuration file:

N/A

• Alertmanager configuration file:

N/A

[pmalek-sumo]

The consequence of this is also https://pkg.go.dev/github.com/prometheus/prometheus not showing a proper version listing and showing Version v1.8.2 as the latest version of Prometheus module.

[beorn7]

Yes, this is a known issue, which has been discussed extensively. There is no conclusion yet how to deal with this. See #7991, #7663, and what's linked thereof, and even more issues…

The root problem here is that prometheus/prometheus uses semantic versioning for the released software product, while Go modules uses semantic versioning for what's essentially the interface of a library. That would not collide if Go modules had chosen a somewhat unique tag naming schema (like go-module-v1.2.3). However, Go modules uses (deliberately) the usual naming schema for tags (v1.2.3), so Go modules erroneously sees releases of the Prometheus server as Go module versions.

An attempt to solve this with tooling is https://github.com/modularise/modularise . https://github.com/modularise shows you a few extracted modules with proper Go modules versioning. The Prometheus team is aware of the problem, but it was decided that we want to wait how this tool and other possible attempts play out before making a call how to address this officially

[roidelapluie]

We have looked at this during our bug scrub, and decided to close this issue as per above comment. This has been discussed already and it seems practically difficult to stick to semver for our go API's.

We have also added that as an agenda point for a future dev summit, where we will discuss it further.

[beorn7]

We will also assess the experience so far with https://github.com/modularise .

[pmalek-sumo]

Understood. Just one last question in this subject: are there any intentions to stick to with Go semver from v3 (whenever this happens)?

[beorn7]

As said, semantic versioning of Prometheus server releases is completely orthogonal to versioning of Go packages. Therefore, I see no way how we could make it the same from v3 onwards.

[DeviaVir]

If you need to use v2.24.1 for some reason immediately, you can use a tag on my fork based on this branch: master...DeviaVir:v2.24.1-v2-branch

The tag is https://github.com/DeviaVir/prometheus/releases/tag/v2.24.1

and you can use it in your go.mod as follows:

module github.com/some/module

go 1.15

replace github.com/prometheus/prometheus/v2 v2.24.1 => github.com/DeviaVir/prometheus/v2 v2.24.1

replace github.com/prometheus/prometheus v2.24.1+incompatible => github.com/DeviaVir/prometheus/v2 v2.24.1

require (
	github.com/prometheus/prometheus/v2 v2.24.1 // indirect
)

This is obviously just a "hack" to allow you to use prometheus inside your modules, I hope the prometheus team is able to work out the problems they face.