The default value of "false" for check-latest in the proposed v2-preview is a dramatic and unwelcome change in behavior, and one that will be hard to change if v2.0 ends up being released with this surprising default behavior in place.

The current default behavior (check-latest: false) silently overrides the expected meaning of the SemVer specified java-version [which is, properly, a required property]. In place of the specified SemVer version, it may silently deliver some non-matching and/or stale versions of the JDK, resulting in different-than-expected behaviors.

See #141 for some discussion about the addition of the check latest property and about its default value..

An option to not actually get the latest version that matches the provided SemVer version spec may make sense in some use cases. In those case, people who want this new an non-intuitive behavior (of semi-randomly picking a version based on what happen to be on the image used, and of not updating to the latest versions even when new versions become available) in order to gain some temporary speed benefits for some specific distro versions, can choose to turn the option on by saying "check-latest: false". But since doing that this is a clear counter-to-best-practice behavior from a configuration control point of view, it should be something you choose to do explicitly, and definitely not be the default behavior.

Let's be clear on somatic meaning here: "check-latest: false" is the semantic equivalent of the following statements:
"Actually include the security fixes expected in the specified version": false.
"Actually include the bug fixes expected in the specified version": false.
"Actually include the behavior enhancements expected in the specified version": false.
"Actually include the new bugs introduced in the specified version": false.

Non of those are a good "default" behavior in e.g. a CI/CD environment. Especially so in an ecosystem where distros update 4-6 times a year, with a well published list of 100s of changes and often 10s of security changes.

And yes, "test my repo against the latest released version of Java 11" is a common, best practice thing to do, with the expectation that tests started after the release and dissemination of a new version will run on that new version, and with the intent of finding out if that latest release breaks your stuff. As a practical example, OpenJDK 11.0.9 broke a bunch of stuff that was detected this way, with breakages widely detected in CI/CD systems the first couple of days after GA releases, leading to the subsequent urgent release of Op[enJDK 11.0.9.1.

Bottom line: if the check-latest properly is kept in v2.x, it should default to true.