Skip to content

Conversation

cl-bvl
Copy link

@cl-bvl cl-bvl commented Aug 23, 2025

Hello.
While working on #1854 I ran into a few typing issues that got in the way:

  1. Most types like Counter, Gauge, Histogram, and Summary have both an interface and a concrete private implementation (counter, gauge, etc.) that implements it. But for the vector types (CounterVec, GaugeVec) there’s no interface — they’re implemented directly. I introduced interfaces for these vector types and moved the implementations into private types (counterVec, gaugeVec).

  2. The ObserverVec interface for HistogramVec and SummaryVec implements all its methods and also satisfies Collector. However, for Histogram and Summary, the Observer interface only defines Observe(float64). This prevents creating a generic interface for Histogram and Summary in places that require a Collector implementation. I added the missing methods to Observer and introduced a new ObserverMetod interface.

  3. Added the missing methods to ObserverVec.

  4. All *Vec types use MetricVec under the hood. I also turned MetricVec into an interface.

  5. I tried to maintain maximum backward compatibility to minimize the likelihood of changes in existing projects.
    In most cases, everything will work without changes or with minimal changes (for example, replacing type from pointer to the interface -- *CounerVec => CounerVec)

cl-bvl added 2 commits August 23, 2025 01:46
Signed-off-by: Vladimir Buyanov <[email protected]>
Signed-off-by: Vladimir Buyanov <[email protected]>
Copy link
Member

@bwplotka bwplotka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

This is great in general, but unfortunately, given a high adoption of this library, we need to embrace an extremely low tolerance bar for breaking changes. Those minimal changes, multiplied by hundreds of thousands importers mean combined effort of likely a multiple SWEyears without notice (next automatic pull of the release of client_golang). There are things we could do without breaking changed, but even replacing struct with interfaces etc is hard to accept now.

However, we were always thinking about v2, you can find many issues/ideas that require v2 on our board, so perhaps it's time to start something together on a branch of directory? With generics now, things might be bit easier. V2 will be a long process to get, and it will need to be 10x easier to use to get ppl on it... but we need to start it one day (:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants