On Thu, 7 Mar 2024 17:32:02 GMT, Frederic Thevenet <ftheve...@openjdk.org> wrote:
> Also, it might be worth repeating one of my long-standing wishes: that the > version string should not be hard-coded into the build, but e.g. stored as a > string in the `release` file, and read from there. If we did that, the cost > of changing the version string would be negligible, and we wouldn't need to > worry as much about it. It would also be simple to compare different builds > which end up with the same bits since they are built from the same sources, > but by different version flags (e.g. -ea vs GA). (In fact, we'd turn a -ea > build into a GA just by updating the version string, so we'd know for sure we > are publishing what we tested.) This certainly sounds like it has the potential to solve a lot of these kind of problems. I would point out that, if you can flip the EA status in the text file, someone could also easily masquerade a build as something completely different from what it is. However, it is already possible to create a build like this via the `configure` options so it's really only a slight change in accessibility. For example, if I specify `--with-version-feature=11`, I can produce: ~~~ $ /home/andrew/builder/fake11/images/jdk/bin/java -version openjdk version "11-internal" 2024-09-17 OpenJDK Runtime Environment (fastdebug build 11-internal-adhoc.andrew.jdk) OpenJDK 64-Bit Server VM (fastdebug build 11-internal-adhoc.andrew.jdk, mixed mode, sharing) $ /home/andrew/builder/fake11/images/jdk/bin/java -Xinternalversion OpenJDK 64-Bit Server VM (fastdebug 11-internal-adhoc.andrew.jdk) for linux-amd64 JRE (11-internal-adhoc.andrew.jdk), built on 2024-03-07T19:41:08Z with gcc 13.2.1 20230826 ~~~ despite the fact that the source code I've built is actually an in-development JDK 23. All we'd be doing is moving that into a text file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1984317603
