`Version.getCurrent()` not consistent with the new version scheme

[zakkak]

Describe the issue
#6302 introduced a new version scheme for GraalVM and changed the output of native-image --version

An issue with this change is that Version.getCurrent(), which AFAIK is public API still returns 23.0.1 instead of 17.0.7+4.1. So tools and frameworks are expected to be able to understand both and somehow map one to the other, since pre-build they might rely on the output of native-image --version but at build-time they might use Version.getCurrent().

cc @jerboaa @fniephaus

[fniephaus]

We aren't going to switch Version.getCurrent() to the new version scheme in the upcoming release, so it will return something like 23.0.0. Although part of the public API, it's not directly used by many end-users. Nonetheless, using Version.getCurrent() is discouraged from now on and I expect it to be deprecated soon.

[zakkak]

If the use of Version.getCurrent() is discouraged and expected to get deprecated and ultimately removed, moving forward what is the proper way of programmatically figuring out the exact GraalVM CE version (and not just the exact JDK version it was built on)?

[fniephaus]

If you need to check for a specific GraalVM build number, I'd say something is wrong, either on our or on your side. In that case, you might as well check the vendor version (or use Version.getCurrent() while it is still there). Patch releases usually also come with updated JDK versions if you, for some reason, care about patch levels. Note that we also don't change the versioning scheme for our Maven artifacts in this release.
In general, I expect checking against a specific JDK version (via Runtime.version() for example) should cover the vast majority of use cases, if not all.