On Thu, 28 Oct 2021 09:48:13 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
>> Current adhoc version build strings are not ideal. Some of the problems: >> * A build number of "0" is inserted, which make the version string look >> like it's an official build, at least when not reading carefully >> * The version string gives little indication on what source code the build >> was based >> >> Also, an error was discovered in how the build system generates version >> strings without a build number (since this basically never happened before). >> A version without a build number, and without a PRE value, but with an OPT >> value, should have a "+-" separator, according to JEP 223. While this was >> correctly handled, the "+-" separator was also applied to versions without a >> build, but with both PRE and OPT. In this case, the "+" should be omitted, >> according to JEP 223. This bug is fixed by this commit. >> >> Ideally, the adhoc version string should include something along the lines >> of the output of `git describe`. However, since the version string is set at >> configure time, not build time, this will almost immediately become >> misleading. :-( A substitute is proposed in this patch, where the branch >> name is included in the OPT string (if it's not `master`). >> >> Finally, this patch fixes hotspot so it can properly build without a build >> number. This was the last blocker for why the build system always required >> the "0" as build number before. To facilitate interoperability with external >> tools (like jib) that still sets build number to "0" to really signal "no >> build number", a build number exactly matching "0" will be interpreted as >> having no build number. > > make/autoconf/jdk-version.m4 line 243: > >> 241: if test "x$NO_DEFAULT_VERSION_PARTS" != xtrue; then >> 242: # Default is to calculate a string like this: >> 243: # 'adhoc.<username>.<base dir name>[.<git branch>]' > > I like this idea, but I think it suffers from the same trouble as plain `git > describe`. It is possible to switch between git branches without needing to > reconfigure, for example where branch had not deviated from master all that > much. It seems this can only be captured properly at build time... Yeah, you're probably right. It matches my workflow, but there is no guarantee about that. I'll remove this part. ------------- PR: https://git.openjdk.java.net/jdk/pull/6152
