JEP 223: New Version-String Scheme

Florian Weimer fweimer at redhat.com
Fri Nov 14 21:38:11 UTC 2014


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


More information about the platform-jep-discuss mailing list