JEP 223: New Version-String Scheme

[Iris Clark]

Hi, Florian.

Thanks for the clarification.  Since situation you describe is getting into binary release policy, I can only provide options for how the new version-string scheme could be used by downstream consumers of the JDK code base (including Oracle).  Ultimately, the decision of what binary releases use to identify their release is at the discretion of the entity shipping the binary release.

> Our platform has external metadata (independent of files shipped as part of OpenJDK), identifying the exact version of the build.  Internal version numbers are therefore redundant, and we generally do not update them if we use minimal security fixes ("backports").  There is often no reasonable choice for a patched version number.  If we had 1.2 and upstream shipped 1.3 with other, unrelated changes, should we label our security patch 1.3, too?  Probably not.  1.2.1?  Upstream might use that version later.  1.2.el8.1?  Might break syntax expectations.  Etc

In no particular order, here are some choices.

- Continue using the existing alternate version identification method.  In your case it sounds like you could continue to not update the version number and rely on external metadata for accurate version identification. 

- Use the version number:  Each downstream consumer could assign specific meaning to the fourth and later version number elements.  For instance, Red Hat could decide that for their releases, element four is defined as $RHSECURITY with an increment policy that matches $SECURITY (or not).  If upstream ships 9.0.1 and Red Hat has need to ship with additional security fixes prior to 9.0.2, the release number could be 9.0.1.1.  I don't see a problem if another downstream consumer ships a slightly different release with an identical version number, just use System.getProperty("java.vendor") to distinguish them.

- Use the version string:  Each downstream consumer could encode additional information in $OPT.  (Be careful because the JEP specifies that the value of $OPT is ignored when comparing two version strings.)

- Coordinate an upstream release with an incremented $SECURITY containing the changes.  This is perhaps the highest overhead solution, but it is what Oracle has done historically and will likely continue doing.  Other downstream consumers could choose to do the same.

There are other options.  Remember that the JEP defines how a JDK version string will be represented in the OpenJDK source.  A binary distribution is free to extend or completely alter this representation to suit their needs.  

Regards,
iris

-----Original Message-----
From: Florian Weimer [mailto:fweimer at redhat.com] 
Sent: Friday, November 14, 2014 1:38 PM
To: Iris Clark; platform-jep-discuss at openjdk.java.net
Subject: Re: JEP 223: New Version-String Scheme

On 11/14/2014 09:37 PM, Iris Clark wrote:
> Hi, Florian.
>
>> Downstreams may have to add additional, out-of-cycle security fixes.
>> Should they avoid changing the version-string altogether if they do this?
>
> Wouldn't you want/need to change the version string (including the version number) for every release so that it can be identified?

Our platform has external metadata (independent of files shipped as part of OpenJDK), identifying the exact version of the build.  Internal version numbers are therefore redundant, and we generally do not update them if we use minimal security fixes ("backports").  There is often no reasonable choice for a patched version number.  If we had 1.2 and upstream shipped 1.3 with other, unrelated changes, should we label our security patch 1.3, too?  Probably not.  1.2.1?  Upstream might use that version later.  1.2.el8.1?  Might break syntax expectations.  Etc.

> It's possible that a Project Lead may wish to coordinate version numbers, but I don't see why it couldn't be changed.

I think this would be rather difficult, for various reasons.

> Perhaps I've misunderstood the question?

I'm just trying to clarify what *your* expectations are regarding downstreams.

--
Florian Weimer / Red Hat Product Security