Breaking change introduced in 1.3.2

[jonatan-ivanov]

It seems 1.3.2 was released with some breaking changes (compared to 1.3.1). This is unexpected given that it is a patch release.

The change was introduced here: eb48f5d#diff-03bebb9eaf09f2cec3a24afb7ff939663924dd8b47ed8612bf5fcef9edd2e018R36

The commit is big, please wait a few seconds so that your browser can load it and jump there, if it does not work, scroll to MetricSnapshots.java#36:

- public MetricSnapshots(Collection<MetricSnapshot> snapshots) {
+ public MetricSnapshots(Collection<MetricSnapshot<?>> snapshots) {

Which can cause compiler errors, it is a breaking change in a public class. In Micrometer, the compiler error we get is:

MicrometerCollector.java:88: error: no suitable constructor found for MetricSnapshots(Collection<MetricSnapshot>)
        return new MetricSnapshots(metricSnapshots);

I think this change was causing compile-time failures in the Prometheus Client during refactor but here is a simple reproducer that is ok with 1.3.1 but fails with 1.3.2:

Collection<MetricSnapshot> collection = new ArrayList<>();
MetricSnapshots metricSnapshots = new MetricSnapshots(collection);

[fstab]

Thanks Jonatan! This wasn't intentional, I think we should revert it and make another patch release.

[zeitlinger]

Yes, I wasn't aware that this is part of the public API (because we have no internal packages).

Otel has already adjusted to this change in open-telemetry/opentelemetry-java#6805 - so we have to decide if want to roll back or just declare it a breaking change.

[shakuzen]

The maintainers here are free to choose what they want to do, and I don't know if there's an explicit versioning/compatibility policy for this project, but I think it would create less potential future issues to revert the breaking change and release a new patch version. As far as I can tell, otel-java has not released a version since merging that change, so it isn't something available to users in a released version yet anyway. Micrometer has a scheduled release on Monday. We can adapt to the change but then that makes our code incompatible with versions of the Prometheus client before this breaking change, which may or not be a problem for users depending on how they manage versions, but it would be generally unexpected for any patch version in a minor to not be a drop-in replacement in terms of API/ABI compatibility.

As a side note, introducing something like japicmp could help catch breaking changes as part of the build.

[zeitlinger]

That's a reasonable ask - I'll create a release this week, which you can include in the next micrometer release.

[zeitlinger]

Fixed in #1189

[jonatan-ivanov]

Thank you, do you have an ETA to release it (1.3.3)?

[zeitlinger]

Thank you, do you have an ETA to release it (1.3.3)?

Nov 8

[zeitlinger]

@jonatan-ivanov https://github.com/prometheus/client_java/releases/tag/v1.3.3

[jonatan-ivanov]

Thank you!