Breaking Change in 1.13.0 - NoClassDefFoundError about micrometer

[TheSench]

Thank you for the extra added context, and for drawing out the key part of the migration guide that we can use io.micrometer:micrometer-registry-prometheus-simpleclient in place of io.micrometer:micrometer-registry-prometheus. This is helpful for others that may be running into unexpected build failures after the recent release.

[jonatan-ivanov]

Please take a look at the Release Notes and the 1.13 Migration Guide.

Here's some background:

• After 9 years of being on 0.x, Prometheus released 1.x with breaking changes
• micrometer-registry-prometheus was migrated to the new 1.x client
• At the same time the original bits of micrometer-registry-prometheus (Prometheus 0.x) were moved to micrometer-registry-prometheus-simpleclient

The decision we needed to make: move to 1.x and offer a way going back to 0.x or stick with 0.x and let users opt-in to the upgrade. We decided to migrate micrometer-registry-prometheus to 1.x and also offer micrometer-registry-prometheus-simpleclient which is the exact copy of micrometer-registry-prometheus before the migration.

The decision you need to make: migrate to 1.x (use micrometer-registry-prometheus) or stay on 0.x (use micrometer-registry-prometheus-simpleclient).

If you want to migrate to the new client, this is the change you should make:

- runtimeOnly 'io.micrometer:micrometer-registry-prometheus:1.12.6'
+ runtimeOnly 'io.micrometer:micrometer-registry-prometheus:1.13.0'

If you do not want to migrate to the new client, this is the change you should make:

- runtimeOnly 'io.micrometer:micrometer-registry-prometheus:1.12.6'
+ runtimeOnly 'io.micrometer:micrometer-registry-prometheus-simpleclient:1.13.0'

(Please notice that you need to change the version number and the name of the artifact in this case.)

If you use a framework that auto-configures things for you, like Spring Boot, I think the change should be transparent to you since Boot auto-configures the new client for you. Excluding some cases for example using the Prometheus API directly or the old PrometheusMeterRegistry. In that case instead of depending on PrometheusMeterRegistry, you should depend on MeterRegistry.

[TheSench]

@jonatan-ivanov Our challenge was that we were receiving this dependency transiently and the dependency that pulled it in was pulling it in via latest.release (yes, I agree that this is not a great idea), which forced it to use 1.13.0. We did not choose to migrate to 1.13.0, but we started encountering unexpected build failures as soon as this version was released.

I'm not well-versed enough in my Gradle dependency management to know when it automatically pulls in a higher minor version outside of latest.release (my assumption is that it typically doesn't).

That said, 0.x Prometheus may have made a major version change to 1.x, but this specific library had breaking changes in a minor version bump, which feels incorrect. In these cases, I would usually expect a 2.x release of micrometer-registry-prometheus.

[jonatan-ivanov]

Our challenge was that we were receiving this dependency transiently and the dependency that pulled it in was pulling it in via latest.release (yes, I agree that this is not a great idea), which forced it to use 1.13.0. We did not choose to migrate to 1.13.0, but we started encountering unexpected build failures as soon as this version was released.

From latest.release perspective you were broken if this would have happened in a major release, i.e.: Micrometer 2.0.0. How the component that brings this in transitively not broken, did they migrate? (Btw migration should be simple, most of the time is a package name change but please check the migration guide.) Can you ask them to bring in micrometer-registry-prometheus-simpleclient instead?

With latest.release you are sitting on multiple ticking bombs. (I also recommend using dependency lock files.)

I'm not well-versed enough in my Gradle dependency management to know when it automatically pulls in a higher minor version outside of latest.release (my assumption is that it typically doesn't).

latest.release always pulls in the latest (hence the name), if someone releases a new major version and breaks everything, it pulls that in. major.+ (1.+) is usually a safer bet.
In Gradle, you can exclude micrometer-registry-prometheus and pull in micrometer-registry-prometheus-simpleclient, you have control over what is transitively pulled in/not pulled in.

That said, 0.x Prometheus may have made a major version change to 1.x, but this specific library had breaking changes in a minor version bump, which feels incorrect. In these cases, I would usually expect a 2.x release of micrometer-registry-prometheus.

Last time we tried to do 2.x, we were not able to because of users/other libraries who did not want to migrate and breaking changes. :) I explained above what were our two options (2.0 is not really right now I think) and we are trying our best not to break people but is this change really that breaking when the fix is updating the name with the version? You don't need to change your code, but the dependency what you also do with the version.