On 2020-08-26 17:01, Erik Joelsson wrote:
I realized that for LTS releases, the logic adding a numeric only $OPT
string will bail out as we (Oracle) are then adding LTS to the $OPT
string. To fix this, I've added an explicit setting of the new
configure parameter --with-macosx-bundle-build-version from the jib
configuration for CI builds.
New webrev, only difference is in jib-profiles.js.
http://cr.openjdk.java.net/~erikj/8252145/webrev.02/
Looks good to me. Thanks for cleaning this up!
/Magnus
/Erik
On 2020-08-25 16:35, Sergey Bylokhov wrote:
Looks fine.
On 25.08.2020 07:27, Erik Joelsson wrote:
On 2020-08-24 19:18, Sergey Bylokhov wrote:
Hi, Erik.
I would like to highlight one thing affected by this fix. The text
in the default about dialog in the Swing application will be changed.
For my local build:
- Current text: "Java Version 1.0 (16)"
- After the fix: "Java Version 16 (0)"
I am not sure why the build version and as a result the
CFBundleVersion is zero?
The CFBundleVersion is supposed to have a version number
representing the build number. In a developer build, the
"VERSION_BUILD" variable is default 0. In a promoted build, that
number is set to the promoted build number. In Oracle promoted
builds, we will also have a CI build number, so if this change was
in effect, the latest JDK 16 promoted build would have 12.477 in
CFBundleVersion.
/Erik
On 24.08.2020 08:19, Erik Joelsson wrote:
When fixing JDK-8246094, I concluded that our Info.plist files are
in a bit of a mess. This patch tries to address this on a more
fundamental level.
1. All Info.plist files and templates are moved to the same
location in the source tree.
2. The CFBundleIdentifier is changed to no longer contain the
version number. Instead it gets the $VERSION_PRE string if present.
3. The CFBundleShortVersionString is changed to the numeric
version part of our version string.
4. The CFBundleVersion is changed to the build number (or a custom
number if supplied through a new configure argument). For Oracle
builds, this will take the form of
<promotionBuildNumber>.<InternalCIBuildNumber>.
For more details on why this particular scheme, see bug
description, but in short, this is what I think best reflects what
the Apple documentation says the fields are for.
Bug: https://bugs.openjdk.java.net/browse/JDK-8252145
Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01
/Erik
