You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Paul Benedict <pb...@apache.org> on 2014/11/04 23:10:24 UTC
Fwd: JEP 223: New Version-String Scheme
Finally, JDK versioning will be 3 numbers... sort of. The qualifier is
non-standard (plus sign and build number). But it still beats 4 numbers.
Cheers,
Paul
---------- Forwarded message ----------
From: <ma...@oracle.com>
Date: Tue, Nov 4, 2014 at 4:05 PM
Subject: JEP 223: New Version-String Scheme
To: iris.clark@oracle.com
Cc: platform-jep-discuss@openjdk.java.net
New JEP Candidate: http://openjdk.java.net/jeps/223
- Mark
Re: Fwd: JEP 223: New Version-String Scheme
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 05/11/2014 1:18 AM, Mirko Friedenhagen wrote:
> And the scheme as I read it is MAJOR.FEATURE_MINOR.SECURITY.PATCHLEVEL and
> FEATURE_MINOR and SECURITY are sort of independent, so a bigger minor might
> be less secure.
>
> Regards
> Mirko
I gather that the assumption is that 9.2.20 would include all of the
security patches of 9.1.20 and that one would never issue a 9.2.19 after
9.1.20 had been released and that security bugs would always be released
on the higher versions first.
A release pattern of 9.1.19, 9.2.19 and 9.2.20 followed by a backporting
to 9.1.20 would be expected rather than
9.1.19, 9.2.19, 9.1.20 followed by 9.2.20.
However, the second release pattern might come about if the 9.2.19
release is not widely adopted and there is a lot of interest in fixing
the security problem in 9.1.19 since it is in more production
environments or in the environment of the person doing the patching.
Version numbers in and of themselves do not guarantee security but at
least you can easily see that a 9.2.21 release has at least some
security flaw fixed that 9.2.20 did not but it does not have any added
functionality.
It also makes it easier to discuss security.
9.x.20 includes fixes security issues 6789,6897, 6899
9.x.21 includes fixes for security issues 6931,6944
If the security patches are backported, one could easily see that 9.1.21
and 9.2.21 have the same security patches applied (unless some only
apply to new features in 9.2.20 that do not cause a security problem in
9.1.20).
If none of the security patches in 9.2.21 apply to 9.1.20, does one
still issue a 9.1.21 just to signal that it is just as secure as 9.2.21
even though none of the x.x.21 patches were applied?
When security patches apply to different major versions, one has to do a
bit of reading to find out that 8.3.35 (actually 8.x.35) has the same
security patches (at least the ones that apply) as 9.2.21(9.x.21).
Security release 34 in release 8.x.34 is not as secure as 21 in 9.x.21
but 9.x.21 is just as secure as 8.x.35.
Ron
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Fwd: JEP 223: New Version-String Scheme
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 05/11/2014 1:18 AM, Mirko Friedenhagen wrote:
> And the scheme as I read it is MAJOR.FEATURE_MINOR.SECURITY.PATCHLEVEL and
> FEATURE_MINOR and SECURITY are sort of independent, so a bigger minor might
> be less secure.
>
> Regards
> Mirko
I gather that the assumption is that 9.2.20 would include all of the
security patches of 9.1.20 and that one would never issue a 9.2.19 after
9.1.20 had been released and that security bugs would always be released
on the higher versions first.
A release pattern of 9.1.19, 9.2.19 and 9.2.20 followed by a backporting
to 9.1.20 would be expected rather than
9.1.19, 9.2.19, 9.1.20 followed by 9.2.20.
However, the second release pattern might come about if the 9.2.19
release is not widely adopted and there is a lot of interest in fixing
the security problem in 9.1.19 since it is in more production
environments or in the environment of the person doing the patching.
Version numbers in and of themselves do not guarantee security but at
least you can easily see that a 9.2.21 release has at least some
security flaw fixed that 9.2.20 did not but it does not have any added
functionality.
It also makes it easier to discuss security.
9.x.20 includes fixes security issues 6789,6897, 6899
9.x.21 includes fixes for security issues 6931,6944
If the security patches are backported, one could easily see that 9.1.21
and 9.2.21 have the same security patches applied (unless some only
apply to new features in 9.2.20 that do not cause a security problem in
9.1.20).
If none of the security patches in 9.2.21 apply to 9.1.20, does one
still issue a 9.1.21 just to signal that it is just as secure as 9.2.21
even though none of the x.x.21 patches were applied?
When security patches apply to different major versions, one has to do a
bit of reading to find out that 8.3.35 (actually 8.x.35) has the same
security patches (at least the ones that apply) as 9.2.21(9.x.21).
Security release 34 in release 8.x.34 is not as secure as 21 in 9.x.21
but 9.x.21 is just as secure as 8.x.35.
Ron
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Fwd: JEP 223: New Version-String Scheme
Posted by Mirko Friedenhagen <mf...@gmail.com>.
And the scheme as I read it is MAJOR.FEATURE_MINOR.SECURITY.PATCHLEVEL and
FEATURE_MINOR and SECURITY are sort of independent, so a bigger minor might
be less secure.
Regards
Mirko
--
Sent from my mobile
On Nov 4, 2014 11:10 PM, "Paul Benedict" <pb...@apache.org> wrote:
> Finally, JDK versioning will be 3 numbers... sort of. The qualifier is
> non-standard (plus sign and build number). But it still beats 4 numbers.
>
> Cheers,
> Paul
>
> ---------- Forwarded message ----------
> From: <ma...@oracle.com>
> Date: Tue, Nov 4, 2014 at 4:05 PM
> Subject: JEP 223: New Version-String Scheme
> To: iris.clark@oracle.com
> Cc: platform-jep-discuss@openjdk.java.net
>
>
> New JEP Candidate: http://openjdk.java.net/jeps/223
>
> - Mark
>
Re: Fwd: JEP 223: New Version-String Scheme
Posted by Mirko Friedenhagen <mf...@gmail.com>.
And the scheme as I read it is MAJOR.FEATURE_MINOR.SECURITY.PATCHLEVEL and
FEATURE_MINOR and SECURITY are sort of independent, so a bigger minor might
be less secure.
Regards
Mirko
--
Sent from my mobile
On Nov 4, 2014 11:10 PM, "Paul Benedict" <pb...@apache.org> wrote:
> Finally, JDK versioning will be 3 numbers... sort of. The qualifier is
> non-standard (plus sign and build number). But it still beats 4 numbers.
>
> Cheers,
> Paul
>
> ---------- Forwarded message ----------
> From: <ma...@oracle.com>
> Date: Tue, Nov 4, 2014 at 4:05 PM
> Subject: JEP 223: New Version-String Scheme
> To: iris.clark@oracle.com
> Cc: platform-jep-discuss@openjdk.java.net
>
>
> New JEP Candidate: http://openjdk.java.net/jeps/223
>
> - Mark
>