@gilles-duboscq how do you plan to handle releases that might need to be built on exactly the same JDK as a previous GraalVM release moving forward? Are such releases no longer an option?

I'm thinking of 2 options that would probably be less confusion than this extra .X in there:

• use the fifth digit of the jdk version (e.g., 21.0.0.0.1) either in the labsjdk itself (meaning it needs to be re-built) or just in the vendor version (which can be updated just via jlink).
• Add something in java.vm.version and/or java.runtime.version (that does mean re-building a labsjdk)
  What do you think?

What do you think?

I personally prefer the vendor version approach, but there is a discussion in quarkusio/quarkus#34161 about using the release file to get the version, and I am afraid the vendor version is not reflected there. Anything requiring rebuilding labsjdk, while nothing changes in it, doesn't feel right to me but at the same time it shouldn't really affect us (either on the Mandrel side or the Quarkus side).

cc @jerboaa @Karm

Personally: That's what the vendor version is for in OpenJDK.

What is the plan for maven artifacts? Is the plan to keep the old version scheme for them? I.e. how does a graal-js dependency look like in a pom going forward?