After giving it more search, it came to (my) light that go mod handles "special" git tags for go mod sub-versioning.
https://github.com/golang/go/wiki/Modules#what-are-multi-module-repositories The tag for version 1.2.3 of module "my-repo/foo/rop" is "foo/rop/v1.2.3". > I.E, "go get github.com/prometheus/prometheus/tsdb/[email protected]" would resolve "github.com/prometheus/prometheus.git" at tag "tsdb/v2.13.0" With that in mind, I believe having multiple independent go modules in the same git repo is OK. With this we can leverage the initial reason of having those "core" modules inside prometheus/prometheus (no sync overhead) and a decent independent development oriented life cycle. We currently have release shepherds, I think that if we were to implement this, we would need a shepherd per module responsible for releasing versions of "his" module(s). I made a Draft PR to get a sense of it: https://github.com/prometheus/prometheus/pull/6888/commits/44149825edb0b5c92885f362b6f3ae1643e2f451 It's pretty light if we exclude removing vendoring altogether (because I don't believe vendoring makes sense anymore with the latest versions of go and because each module having its own go mod needs its own vendor/ dir). The only problem I encountered came from promu. In the case we want to build a binary in a module that has its own go.mod file (like tsdb), the go build command needs to be run from within the dir of the module (because of the relative paths in the go.mod replace directive I assume). I already have a patch for this ( https://github.com/sylr/promu/commit/c6e6a2bcdf5d50338b1ee70022c40152a8992c82 ). Regards. On Fri, 7 Feb 2020 at 18:12, Bjoern Rabenstein <[email protected]> wrote: > I think it became already obvious from the discussion so far: Semantic > versioning for the user of the Prometheus server is completely > different from semantic versioning for the user of Go packages > contained in the Prometheus code base. > > Conflating both will be bad for both parties. > > We could have a _separate_ versioning, using vx.y.z tags for the Go > module versioning and a new tag naming schema (e.g. release-x.y.z) for > user releases. > > Besides the obvious concerns about this, I also think that semantic > versioning for a large number of Go packages together is problematic > in any case. Any breaking change in any one package will bump the > major version for _all_ packages, leading to new import paths in the > Go modules world, which can lead to interoperability problems for > indirect users of the packages. (They could find themselves in the > situation of assigning a v2/model.Label spit out by one of their > direct dependencies to a v3/model.Label required by another of their > direct dependencies.) > > That's why I think Duco's Modularize project has some > merits. Alternatively (as I said before), I could see better tooling > for maintaining multiple Go modules within the same Git repo as a > viable (and less invasive) solution. > > Therefore, I'd prefer to see how Modularize turns out in practice (or > if alternatively somebody comes up with tooling and/or easy-to-follow > best practices for multi-module repos) and then reconsider what we can > do in prometheus/prometheus. > > -- > Björn Rabenstein > [PGP-ID] 0x851C3DA17D748D03 > [email] [email protected] > -- Sylvain Rabot <[email protected]> -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CADjtP1FkVUSFx8hJpe10pTS3d4P_5NKHThu8nORKvyYJHCCavA%40mail.gmail.com.
