Version and Security

[Paul Benedict]

Remi, thanks for the reply. I am not sure what you said is very important
for ops. You can call the filename installer anything you want and document
the patches however. That's what ops are looking for in deciding when/how
to upgrade. So that doesn't mean the official versioning of the product has
to encode security iterations. I refer back to Martin's email regarding how
confusing the last digit is. I don't believe this is the way to go.
On Jan 12, 2016 6:16 AM, "Remi Forax" <forax at univ-mlv.fr> wrote:

> Hi Paul,
> while using dates to indicate the last security patch is interesting,
> you want the version of the produced artifact to reflect the security
> patch level to ease the work of the ops.
>
> Rémi
>
> ----- Mail original -----
> > De: "Paul Benedict" <pbenedict at apache.org>
> > À: verona-dev at openjdk.java.net
> > Envoyé: Lundi 11 Janvier 2016 21:47:55
> > Objet: Version and Security
> >
> > I'd like to offer a suggestion. I am late to the game with this idea,
> but I
> > think it's worth mentioning. Right now I think the proposed encoding is
> too
> > complex and would like an alternative.
> >
> > I don't think the JDK version string should include any special encoding
> > for security. I believe product versioning and security patch versioning
> > should be made clear by 2 different system properties. There should be an
> > additional "security patch level" property that corresponds to the
> version
> > (or date) of either OpenJDK and/or Oracle for whatever their statuses
> are.
> >
> > Example strings:
> > java.version=9.0.1
> > openjdk.java.security.level=2016-01-02
> > oracle.java.security.level=2016-01-11
> >
> > How to interpret this example:
> > Java 9.0.1 has all security patches from OpenJDK since 2016-01-02 and,
> > because my example is using an Oracle JDK, it includes their own
> > proprietary security patches up to 2016-01-11.
> >
> > Cheers,
> > Paul
> >
>