Suggestions & Questions

[Martin Buchholz]

Hi,

I'm one of the people updating all the regexes referring to jdk versions.

Version numbers would be more machine parsable if they consistently
used simply X.Y.Z as the Semantic Versioning folks suggest, but I can
see it's desirable to mark early access versions clearly.  Currently
we use -ea.  In the past -beta and -rc were used as well, and it would
be nice if we could predict that.  I don't think -beta and -rc proved
very useful; I would stick with a single simple predictable -ea.

I don't think it's useful to drop the Y and Z just because they're 0.
The GA build has historically been special, but "9.0.0" is special
enough and familiar and conveys the right expectations.  In the real
world, the GA build does not get used in production.

JEP 223 says, """The sequence of numerals in a version number is
compared to another such sequence in numerical, pointwise fashion;
e.g., 9.9.1 is less than 9.10.0."""

That's unclear to me - in what way are the version numbers being
compared?  What does this sort order mean exactly?  9.9.1 is "less"
than 9.10.0, but has more security patches applied and was released
later in time?

"""$SECURITY is reset to zero only when $MAJOR is incremented. A
higher value of $SECURITY for a given $MAJOR value, therefore, always
indicates a more secure release, regardless of the value of $MINOR."""

This is surprising.  Users of jdk9 will need to update to new MINOR
releases anyways to get their security updates, because old MINOR
releases don't get security updates (although icedtea sister project
does do that).  OTOH people often use multiple MAJOR versions for
years, and there it would be more useful to be able to compare
security patch levels, especially given that security patches are
released simultaneously.  But following that logic would require a
global incrementing number whenever a security update happens; are we
ready for jdk-13.1.43 coincident with jdk-12.4.43?  I'd say either
always reset $SECURITY to 0 or always increment it - the former is
more consistent with Semantic Versioning.  Maybe security information
"October CPU" could be stuffed into the optional part of the version
string?

(Google's internal version scheme has also built up serious cruft)