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