Please a make a new release / tag

[AlekSi]

No description provided.

[beorn7]

We don't really do releases or tags in this repo. What do you need it for?

[AlekSi]

Sorry, I missed your reply.

The general problem I try to solve is a bad experience of adding/updating a vendored copy of client_golang and related repositories. I created a repository with the basic example from this package: https://github.com/AlekSi/prometheus-vendoring-example It has the following dependencies:

  Locking in master (4c0e845) for transitive dep github.com/beorn7/perks
  Locking in master (e645f4e) for transitive dep github.com/prometheus/procfs
  Locking in v1.0.0 (3247c84) for transitive dep github.com/matttproud/golang_protobuf_extensions
  Locking in v0.8.0 (c5b7fcc) for transitive dep github.com/prometheus/client_golang
  Locking in master (6a1fa94) for transitive dep github.com/golang/protobuf
  Locking in master (3e6a763) for transitive dep github.com/prometheus/common
  Locking in master (6f38060) for transitive dep github.com/prometheus/client_model

Updating them is a very frustrating process. Should I stick with some randomly-looking hashes of common and client_model? What should I do if it's not compiling? Should I update to master while keeping client_golang at v0.8.0? And so on.

Personally, I would like to have a fewer number of repositories. Maybe smaller bits like perks and golang_protobuf_extensions can be absorbed into large bits like common? And I would like to have remaining repositories to have tagged releases, it will definitely give me some idea from what version to what version I'm updating.

What do you think?

[beorn7]

This touches a discussion that has been ongoing for as long as Go exists. It boils down to: How to vendor dependencies in libraries, if at all? in fact, we tried many things in Prometheus land, always ending up at the point where we did not vendor anything in libraries. This has many problems, but all solution we tried stirred up different, but even more problems.

Coming back to the original request: How would a tag or "release" in client_model help?

[AlekSi]

I absolutely agree that it's not a good idea to use vendor/ with a library packages. But you can add a package to existing repository. In my opinion, github.com/prometheus/common/perks and github.com/prometheus/common/golang_protobuf_extensions is slightly better than 3 different repositories. If you can refactor perks so it fits more naturally into common, that's even better. Maybe client_model can go there too?

[beorn7]

perks is a fork of an existing 3rd party repo. (I forked it because the owner wasn't responding to critical bug fixes.) Copying code over is probably possible license wise but needs some care.

Same for golang_protobuf_extensions.

Copying of that kind is essentially vendoring under a different name. We, in fact, tried that at some point and reverted again.

About the mapping between Go packages and GitHub repos: We had changes and discussions about that, too.

I think this is a more general issue how we should deal with that in the project as a whole. And as you can see from the history of the debate, there is no clear-cut solution. It's fair game to revive that discussion, but I suggest the developers mailing list for that: https://groups.google.com/forum/#!forum/prometheus-developers

I'll close this issue here. Feel free to link to it from the mailing list, though.