Version and Security

[Paul Benedict]

Remi, one more addition from me. If the intent is really to flag which
version has security fixes, you can use a qualifier for that. For example,
Spring releases with the .SEC qualifier. The numbering is just an
iteration; but no need to specify how many security iterations there has
been in the version.

Cheers,
Paul

On Tue, Jan 12, 2016 at 7:12 AM, Paul Benedict <pbenedict at apache.org> wrote:

> 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
>> >
>>
>