[Cryptoloveer]

Problem

NodeMetricProvider converts the application version to a Double before registering the metric. That works for two-part values such as 2.1, but semantic versions such as 7.0.2 cannot be represented as a Double; toDoubleOrNull() therefore falls back to 0.0. The exported version tag consequently loses the actual release version.

Fix

Treat node.version as an information-style gauge:

• keep its numeric sample at the conventional constant value 1;
• preserve the normalized application version as the version tag;
• continue removing a pre-release suffix such as -SNAPSHOT, matching the existing behavior.

Validation

Added focused tests covering:

• a three-part semantic version with a -SNAPSHOT suffix;
• the local development fallback value;
• the gauge's constant information value.

The change is limited to node-version metric registration and its tests.

[rotilho]

Thanks for the PR!

Atto node releases use a two-component version format (e.g. 1.35), so the semantic-version case addressed here does not affect the node.

This change would also make the node.version gauge value always 1.0, moving the actual version entirely to the tag, which changes the current semantics of the metric.

There is, however, a known issue when the node version ends in 0, for example 1.30, which is currently exposed as 1.3. This is a limitation of representing the version as a numeric Micrometer gauge, since the value is stored as a Double and therefore cannot preserve trailing zeros.

[Cryptoloveer]

Thanks for explaining the node’s two-component versioning and the intended gauge semantics. This PR addresses the wrong version case and changes the metric behavior in a way that is not appropriate, so I’m closing it. I won’t submit a replacement for the trailing-zero limitation without first agreeing on the desired representation.