From mark.reinhold at oracle.com Tue Nov 4 22:05:33 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 4 Nov 2014 14:05:33 -0800 (PST) Subject: JEP 223: New Version-String Scheme Message-ID: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/223 - Mark From pbenedict at apache.org Tue Nov 4 22:23:01 2014 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 4 Nov 2014 16:23:01 -0600 Subject: JEP 223: New Version-String Scheme Message-ID: I was happy to read through the proposal until the qualifier portion of the "long" version scheme. I don't think the plus sign should be favored over current conventions like OSGi (the dot) or Maven (the dash). Seeing a version like 7.4.10.b11 or 7.4.10-b11 should be favored, in my opinion, as the world is already familiar with these qualifier notations. Cheers, Paul On Tue, Nov 4, 2014 at 4:05 PM, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/223 > > - Mark > From forax at univ-mlv.fr Wed Nov 5 07:53:23 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 05 Nov 2014 08:53:23 +0100 Subject: JEP 223: New Version-String Scheme In-Reply-To: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> Message-ID: <5459D773.1000602@univ-mlv.fr> On 11/04/2014 11:05 PM, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/223 > > - Mark Hi Mark, I fail to see why dropping the first 1 is interesting. While it's true than $MAJOR will be always '1', and that each release slightly violating the principle of semantic versioning, it see that more like the difference between a principle and the reality than something that has to be fixed. IMO, having a difference between the marketing name and the engineering version value doesn't worth the trouble of the compatibility issues you list. Why not stick with a 4 components version ? And for the API, version() should be versions() and return an int[] and build() should return an OptionalInt. cheers, R?mi From martijnverburg at gmail.com Wed Nov 5 11:09:36 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 5 Nov 2014 11:09:36 +0000 Subject: JEP 223: New Version-String Scheme In-Reply-To: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> Message-ID: At the risk of bike-shedding... :-) I love the move towards semantic versioning. But I can see a potential clash in people's (and tools!) understanding between the major.minor.patch and major.minor.security. Is there a possibility of using a 4th to indicate security separately from what people will likely assume is strictly the patch level? e.g. 9.0.3.10 Cheers, Martijn On 4 November 2014 22:05, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/223 > > - Mark > From pbenedict at apache.org Wed Nov 5 15:53:29 2014 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 5 Nov 2014 09:53:29 -0600 Subject: JEP 223: New Version-String Scheme In-Reply-To: <5459D773.1000602@univ-mlv.fr> References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> <5459D773.1000602@univ-mlv.fr> Message-ID: I second what Remi says about dropping the 1. In fact, I think it has been a grace it hasn't yet been dropped. It allows you to move to "2" when Oracle (or another future steward) decides to break major backwards compatibility. Until that happens, there really is no logical justification to get rid of the 1. Let's not forget Windows 10 is internally 6.4 -- point being technical numbers are more important than marketing names. Also, semantic versioning is not a form of math. The next version after 1.9 is 1.10 -- not 2.0 -- and then 1.11, etc. The JEP has this wrong. You keep on incrementing the minor version until you're ready to break backwards compatibility. That's where technical Java version 2.0 comes into being. Cheers, Paul On Wed, Nov 5, 2014 at 1:53 AM, Remi Forax wrote: > > On 11/04/2014 11:05 PM, mark.reinhold at oracle.com wrote: > >> New JEP Candidate: http://openjdk.java.net/jeps/223 >> >> - Mark >> > > Hi Mark, > I fail to see why dropping the first 1 is interesting. > While it's true than $MAJOR will be always '1', and that each release > slightly violating the principle of semantic versioning, it see that more > like the difference between a principle and the reality than something that > has to be fixed. > IMO, having a difference between the marketing name and the engineering > version value doesn't worth the trouble of the compatibility issues you > list. > Why not stick with a 4 components version ? > > And for the API, version() should be versions() and return an int[] and > build() should return an OptionalInt. > > cheers, > R?mi > > From iris.clark at oracle.com Wed Nov 5 18:00:57 2014 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 5 Nov 2014 10:00:57 -0800 (PST) Subject: JEP 223: New Version-String Scheme In-Reply-To: References: Message-ID: <87370da3-96a9-4f29-b0a3-ea1f49afa3ad@default> Hi, Paul. ? Thanks for reading the proposal.? The plus (?+?) prior to the build number is the separator defined by the Semantic Versioning Specification [0] , item 10. ? We chose Semantic Versioning because it has been become increasingly popular and is widely used by the JavaScript community and others.? Semantic Versioning fixes some of the perceived problems of Maven and OSGi.? (For instance, in Maven 7.4.1-10 is considered older than 7.4.1-1.)? The use of plus also has the advantage of making parsing easier. ? Regards, Iris ? [0] http://semver.org/ ? From: Paul Benedict [mailto:pbenedict at apache.org] Sent: Tuesday, November 04, 2014 2:23 PM To: OpenJDK Platform JEP Discuss Cc: Iris Clark Subject: Re: JEP 223: New Version-String Scheme ? I was happy to read through the proposal until the qualifier portion of the "long" version scheme. I don't think the plus sign should be favored over current conventions like OSGi (the dot) or Maven (the dash). Seeing a version like 7.4.10.b11 or 7.4.10-b11 should be favored, in my opinion, as the world is already familiar with these qualifier notations. Cheers, Paul ? On Tue, Nov 4, 2014 at 4:05 PM, wrote: New JEP Candidate: http://openjdk.java.net/jeps/223 - Mark ? From mark.reinhold at oracle.com Wed Nov 5 23:56:11 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 05 Nov 2014 15:56:11 -0800 Subject: JEP 223: New Version-String Scheme In-Reply-To: References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net>, Message-ID: <20141105155611.681267@eggemoggin.niobe.net> 2014/11/5 3:09 -0800, martijnverburg at gmail.com: > At the risk of bike-shedding... :-) Heh. Version-string syntax, I have learned the hard way, is the ultimate bike-shed topic. > I love the move towards semantic versioning. But I can see a potential > clash in people's (and tools!) understanding between the major.minor.patch > and major.minor.security. Is there a possibility of using a 4th to indicate > security separately from what people will likely assume is strictly the > patch level? e.g. 9.0.3.10 The proposal as it stands leaves the fourth (and later) version-number elements free for downstream consumers of the JDK code base (including Oracle) to use any way they choose. Some of these consumers may well want more than one element. Putting the security level in the third position makes that both possible and easy to explain. - Mark From iris.clark at oracle.com Wed Nov 5 23:59:24 2014 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 5 Nov 2014 15:59:24 -0800 (PST) Subject: JEP 223: New Version-String Scheme In-Reply-To: <5459D773.1000602@univ-mlv.fr> References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> <5459D773.1000602@univ-mlv.fr> Message-ID: <5b643a6c-44e5-410d-9fbe-456d7b41d2fc@default> Hi, Remi. Thanks for taking time to read the JEP. >> New JEP Candidate: http://openjdk.java.net/jeps/223 > I fail to see why dropping the first 1 is interesting. > > While it's true than $MAJOR will be always '1', and that each release > slightly violating the principle of semantic versioning, it see that more > like the difference between a principle and the reality than something that > has to be fixed. > > IMO, having a difference between the marketing name and the engineering > version value doesn't worth the trouble of the compatibility issues you > list. Do you have any backing data for this? The biggest potential problem we anticipate at this time is existing code which assumes that the initial element is a '1' and just skips it when comparing version numbers. At this point, we suspect that this code is rare, but perhaps that's not correct? Do you know of any other significant risks that we did not list? > And for the API, version() should be versions() and return an int[] > and build() should return an OptionalInt. What is the benefit of using List/array and primitive/reference types in this case? Conversion between them is straight-forward. Regards, iris From iris.clark at oracle.com Wed Nov 5 23:59:32 2014 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 5 Nov 2014 15:59:32 -0800 (PST) Subject: JEP 223: New Version-String Scheme In-Reply-To: References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> <5459D773.1000602@univ-mlv.fr> Message-ID: <099a5035-f81e-4a68-a653-58c3bd2d53d8@default> Hi, Paul. > I second what Remi says about dropping the 1. In fact, I think it has been a > grace it hasn't yet been dropped. It allows you to move to "2" when Oracle > (or another future steward) decides to break major backwards > compatibility. Backwards compatibility has already been broken to various degrees for every major release of the JDK. They're documented on the Compatibility page [0]. We'll have a similar page for JDK 9. Whether these changes is "major" depends on your perspective. > Also, semantic versioning is not a form of math. The next version after 1.9 > is 1.10 -- not 2.0 -- and then 1.11, etc. The JEP has this wrong. I think you misunderstood. In that example, the implication was that we begin incrementing $MAJOR for major releases. Thus, as the next major release, JDK 9 would have a value of "2.0.0". Regards, iris From iris.clark at oracle.com Thu Nov 6 00:02:51 2014 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 5 Nov 2014 16:02:51 -0800 (PST) Subject: JEP 223: New Version-String Scheme In-Reply-To: References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> Message-ID: Hi, Martijn. Thanks for taking the time to read the JEP. Great to hear that you view the move to Semantic Versioning favorably. > Is there a possibility of using a 4th to indicate security separately from > what people will likely assume is strictly the patch level? e.g. 9.0.3.10 The JEP has been carefully written to allow for the possibility of using any number of digits after $SECURITY for further version identification. Regards, iris From forax at univ-mlv.fr Thu Nov 6 01:41:38 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 06 Nov 2014 02:41:38 +0100 Subject: JEP 223: New Version-String Scheme In-Reply-To: <5b643a6c-44e5-410d-9fbe-456d7b41d2fc@default> References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> <5459D773.1000602@univ-mlv.fr> <5b643a6c-44e5-410d-9fbe-456d7b41d2fc@default> Message-ID: <545AD1D2.9070401@univ-mlv.fr> On 11/06/2014 12:59 AM, Iris Clark wrote: > Hi, Remi. > > Thanks for taking time to read the JEP. > >>> New JEP Candidate: http://openjdk.java.net/jeps/223 >> I fail to see why dropping the first 1 is interesting. >> >> While it's true than $MAJOR will be always '1', and that each release >> slightly violating the principle of semantic versioning, it see that more >> like the difference between a principle and the reality than something that >> has to be fixed. >> >> IMO, having a difference between the marketing name and the engineering >> version value doesn't worth the trouble of the compatibility issues you >> list. > Do you have any backing data for this? The biggest potential problem we > anticipate at this time is existing code which assumes that the initial > element is a '1' and just skips it when comparing version numbers. At this > point, we suspect that this code is rare, but perhaps that's not correct? Do > you know of any other significant risks that we did not list? no, I've no more data than you. but you ask the question the wrong way, you want to change something that I think doesn't need to change, so the question is more what is the benefit of removing the first '1' than "we think that there will be no major oops" so we can remove the first '1'. > >> And for the API, version() should be versions() and return an int[] >> and build() should return an OptionalInt. > What is the benefit of using List/array and primitive/reference types in this > case? Conversion between them is straight-forward. What is the benefit to use a List instead of an int[] ? The version will be loaded early in the process, if we can avoid a dependency on java.util.List, I think it's a net gain. > > Regards, > iris cheers, R?mi From magnus.ihse.bursie at oracle.com Fri Nov 7 12:39:11 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 07 Nov 2014 13:39:11 +0100 Subject: JEP 223: New Version-String Scheme Message-ID: <545CBD6F.90708@oracle.com> Great work! I've really been looking forward to this! :-) The old versioning system (or lack thereof) is a constant source of annoyance in the build system. I think the proposal is overall well designed and well thought out. I'm also glad to see the close alignment with semantic versioning and the effort spent at making the string easy to parse. The only thing I stumbled on was some details on the optional post-version number data, and a problem with regard to the parsability. More specifically: (Quotes are from the JEP.) > When comparing two version strings, a string with a pre-release > identifier is always less than one with an equal $VNUM but no such > identifier. Pre-release identifiers are compared numerically when they > consist only of digits, and lexicographically otherwise. The first part of that rule is reasonable, and aligns with semantic versioning (item 9). I'm not so sure about the second part, about comparing pre-release identifiers. First of all, is it necessary? If we are prepared to accept that there exists byte-wise different version strings that does not differ in order comparison (which is how I read the JEP with regard to $BUILD and $OPT), then maybe we should do so for $PRE as well? For instance, is it obvious that you can order "9.0.0-ea+30" and "9.0.0-internal+30" in any meaningful way? And if we really do want to keep an ordering scheme on $PRE, the current description could at least be improved. Is the numerical comparison supposed to be used when comparing two strictly numerical strings, but not if one of them is non-numeric? But would that mean that "9.0.0-3000" is newer than "9.0.0-300" but not newer than "9.0.0-300beta"? And comparing non-numeric $PRE strings in lexicographic order does not really make sense. If "ea" is supposed to be ordered ahead of "internal", then that's just by pure coincidence. If so, a "9.0.0-adhoc" build would order above "9.0.0-ea", even though the intent of "adhoc" is the same as of "internal". Instead, I propose that for two version strings with two different $PRE parts present, no ordering difference should be made. > When comparing two version strings the value of $BUILD, if present, is > always ignored. Here, I'd actually like to suggest the reverse. While there is to me no reason to believe any of "9.0.0-ea+30" and "9.0.0-internal+30" to be ordered ahead of the other, I do believe there is good reason to consider "9.0.0-ea+30" a higher version than "9.0.0-ea+29". More specifically, I'd propose that for two version strings with identical version numbers and $PRE strings, the numerical value of $BUILD will determine versioning order. For different $PRE strings, as before, no ordering difference should be made. > $OPT, matching ([-a-zA-Z0-9]+) --- Additional build information, if > desired. In the case of an internal build this will often contain the > date and time of the build. I'd like to request the underscore (_) sign to be added to the list of allowed characters in $OPT. It is often useful to be able to separate parts of string with _ as well as -, especially since $OPT will typically be used to help developers annotate a build. That will allow having an $OPT string such as ihse-version-test_2014-11-07_11-05. And last, but not least, the suggested version string format: > $VNUM(-$PRE)?(\+$BUILD)?(-$OPT)? is unfortunately not unambiguously parsable. :-( For instance, "9.0.0-foo" could mean either $PRE=foo or $OPT=foo, since both $PRE and $BUILD is optional. There are several ways to solve this. Some suggestions: 1) Requiring that either $PRE or $BUILD must be present if $OPT should be allowed. I think it would be unfortunate to make such requirements, since it will only lead back to the current practice of having a dummy value e.g. "00" for build in cases were it does not make sense to have a $BUILD value. 2) Requiring that the "+" (the $BUILD marker) must be present if $OPT is present, even if $BUILD is empty. For instance, 9.0.0+-foo-opt. While this would be technically in line with the semantic versioning specification, in my opinion, this looks just too ugly. 3) Using a different marker than "-" for introducing $OPT, e.g. underscore. For instance, 9.0.0_foo-opt or 9.0.0-ea-_foo-opt. I think this is a better solution than the ones above, but it is not ideal. It also differs from the semantic versioning rules. 4) Adjusting the format of a version string to $VNUM(-$PRE)?(-$BUILD)?(\+$OPT)?, with the additional requirement that $PRE is a-z only. For instance, 9.0.0-ea-13+test-run-2 or 9.0.0-13+ihse-debug. This would be my preferred choice. If $PRE is restricted to a-zA-Z only, and $BUILD is restricted to 0-9 only, it would be possible to unambigiously parse such a string. I also believe it matches the intent and examples of semantic versioning better. In this case, the combination ($PRE)?(-$BUILD) would correspond to the "pre-release identifier" of section 9 in the semantic versioning specification, and $OPT would correspond to the "build metadata" of section 10. I believe this is a closer match to the intent, than considering $BUILD (together with $OPT) part of the build metadata (as the current JEP proposal does). Limiting $PRE to a-z only does not seem like an a problematic restriction, since the intent (I guess) is to use it for a limited set of well-known "tags" like ea or internal, and not as a free-form field like $OPT. Finally, it is trivial to write a regular expression that matches this format precisely. That is not the case for all of the other suggested solutions. To fully embrace the intentions of the semantic versioning specification, the $PRE and $BUILD should probably be separated by a dot, e.g. 9.0.0-ea.13+test-run-2. But this is not required to follow the specification and make the version string possible to parse unambiguously, and in my personal opinion it makes it harder to read and understand. /Magnus On 4 November 2014 22:05, wrote: > > New JEP Candidate: http://openjdk.java.net/jeps/223 > > - Mark From magnus.ihse.bursie at oracle.com Fri Nov 7 14:33:33 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 07 Nov 2014 15:33:33 +0100 Subject: JEP 223: New Version-String Scheme In-Reply-To: <545CBD6F.90708@oracle.com> References: <545CBD6F.90708@oracle.com> Message-ID: <545CD83D.2030001@oracle.com> On 2014-11-07 13:39, Magnus Ihse Bursie wrote: > 3) Using a different marker than "-" for introducing $OPT, e.g. > underscore. > > For instance, 9.0.0_foo-opt or 9.0.0-ea-_foo-opt. I think this is a > better solution than the ones above, but it is not ideal. It also > differs from the semantic versioning rules. Correction; my example was intented to be " 9.0.0-ea_foo-opt". Also, I'd like to make sure I understand the exampel given in the JEP: > The sequence of numerals in a version number is compared to another > such sequence in numerical, pointwise fashion; /e.g./, |9.9.1| is less > than |9.10.0|. Am I correct in understanding that if once a 9.9.1 released, then 9.10.0 could never be released (since that would mean breaking the rule of monotonically incrementing security numbers)? But if 9.10.0 was released directly after 9.9.0, then later on 9.9.1 could be released. So this means that while 9.10.0 is in some way "newer" since the minor version is higher, it is also "older" in that it was released cronologically earlier, and does not contain the newest security fixes. I think the versioning scheme makes sense, but this situation is perhaps not completely intuitive, and could perhaps be expanded upon in either the JEP or in any other resulting document that will describe the new version system. Maybe what I'm getting at is some kind of discussion on the semantic meaning of ordering two version strings, not just technical discussions on how such ordering is to be achieved. /Magnus From neugens at redhat.com Mon Nov 10 09:57:29 2014 From: neugens at redhat.com (Mario Torre) Date: Mon, 10 Nov 2014 10:57:29 +0100 Subject: JEP 223: New Version-String Scheme In-Reply-To: <545AD1D2.9070401@univ-mlv.fr> References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> <5459D773.1000602@univ-mlv.fr> <5b643a6c-44e5-410d-9fbe-456d7b41d2fc@default> <545AD1D2.9070401@univ-mlv.fr> Message-ID: <1415613449.3847.1.camel@nirvana.localdomain> On Thu, 2014-11-06 at 02:41 +0100, Remi Forax wrote: > On 11/06/2014 12:59 AM, Iris Clark wrote: > > Hi, Remi. > > > > Thanks for taking time to read the JEP. > > > >>> New JEP Candidate: http://openjdk.java.net/jeps/223 > >> I fail to see why dropping the first 1 is interesting. > >> > >> While it's true than $MAJOR will be always '1', and that each release > >> slightly violating the principle of semantic versioning, it see that more > >> like the difference between a principle and the reality than something that > >> has to be fixed. > >> > >> IMO, having a difference between the marketing name and the engineering > >> version value doesn't worth the trouble of the compatibility issues you > >> list. > > Do you have any backing data for this? The biggest potential problem we > > anticipate at this time is existing code which assumes that the initial > > element is a '1' and just skips it when comparing version numbers. At this > > point, we suspect that this code is rare, but perhaps that's not correct? Do > > you know of any other significant risks that we did not list? > > no, I've no more data than you. > > but you ask the question the wrong way, you want to change something > that I think doesn't need to change, > so the question is more what is the benefit of removing the first '1' > than "we think that there will be no major oops" > so we can remove the first '1'. > > > > >> And for the API, version() should be versions() and return an int[] > >> and build() should return an OptionalInt. > > What is the benefit of using List/array and primitive/reference types in this > > case? Conversion between them is straight-forward. > > What is the benefit to use a List instead of an int[] ? > The version will be loaded early in the process, if we can avoid a > dependency on java.util.List, > I think it's a net gain. Arrays are so old fashioned! Mario From neugens at redhat.com Mon Nov 10 10:23:33 2014 From: neugens at redhat.com (Mario Torre) Date: Mon, 10 Nov 2014 11:23:33 +0100 Subject: JEP 223: New Version-String Scheme In-Reply-To: <545CD83D.2030001@oracle.com> References: <545CBD6F.90708@oracle.com> <545CD83D.2030001@oracle.com> Message-ID: <1415615013.3847.3.camel@nirvana.localdomain> On Fri, 2014-11-07 at 15:33 +0100, Magnus Ihse Bursie wrote: > Am I correct in understanding that if once a 9.9.1 released, then > 9.10.0 > could never be released (since that would mean breaking the rule of > monotonically incrementing security numbers)? But if 9.10.0 was > released > directly after 9.9.0, then later on 9.9.1 could be released. I found this a bit confusing too. I suggested myself that while looking at the last number is the ultimate indication for all the security patches, the general case is that when there's a security release, there won't really be concurrently a standard release. If there's one (i.e. fix for an incompatibility added by a security fix) it will be done *after*. So in reality there should never be a case where you have 9.10.0 then 9.10.1 and then 9.11.0. If this occurs, then I guess what you suggest happens, 9.11.0 is a newer jdk, however was build without the security patches of 9.10.1, although this schemes doesn't tell you if if 9.11.0 is a newer *build* over 9.10.1, it only tells you it's a newer feature build. I believe this would be a rare case, but the numbering preserves the important information regarding the security update even. I agree clarifying this step would be good though. Cheers, Mario From forax at univ-mlv.fr Mon Nov 10 11:22:01 2014 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 10 Nov 2014 12:22:01 +0100 Subject: JEP 223: New Version-String Scheme In-Reply-To: <1415613449.3847.1.camel@nirvana.localdomain> References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> <5459D773.1000602@univ-mlv.fr> <5b643a6c-44e5-410d-9fbe-456d7b41d2fc@default> <545AD1D2.9070401@univ-mlv.fr> <1415613449.3847.1.camel@nirvana.localdomain> Message-ID: <5E02A1C7-942D-415B-91F0-BC2B3A1EE7B8@univ-mlv.fr> and java.lang.Integer is not fancy anymore ... R?mi Le 10 novembre 2014 10:57:29 UTC+01:00, Mario Torre a ?crit : >On Thu, 2014-11-06 at 02:41 +0100, Remi Forax wrote: >> On 11/06/2014 12:59 AM, Iris Clark wrote: >> > Hi, Remi. >> > >> > Thanks for taking time to read the JEP. >> > >> >>> New JEP Candidate: http://openjdk.java.net/jeps/223 >> >> I fail to see why dropping the first 1 is interesting. >> >> >> >> While it's true than $MAJOR will be always '1', and that each >release >> >> slightly violating the principle of semantic versioning, it see >that more >> >> like the difference between a principle and the reality than >something that >> >> has to be fixed. >> >> >> >> IMO, having a difference between the marketing name and the >engineering >> >> version value doesn't worth the trouble of the compatibility >issues you >> >> list. >> > Do you have any backing data for this? The biggest potential >problem we >> > anticipate at this time is existing code which assumes that the >initial >> > element is a '1' and just skips it when comparing version numbers. >At this >> > point, we suspect that this code is rare, but perhaps that's not >correct? Do >> > you know of any other significant risks that we did not list? >> >> no, I've no more data than you. >> >> but you ask the question the wrong way, you want to change something >> that I think doesn't need to change, >> so the question is more what is the benefit of removing the first '1' > >> than "we think that there will be no major oops" >> so we can remove the first '1'. >> >> > >> >> And for the API, version() should be versions() and return an >int[] >> >> and build() should return an OptionalInt. >> > What is the benefit of using List/array and primitive/reference >types in this >> > case? Conversion between them is straight-forward. >> >> What is the benefit to use a List instead of an int[] ? >> The version will be loaded early in the process, if we can avoid a >> dependency on java.util.List, >> I think it's a net gain. > >Arrays are so old fashioned! > >Mario -- Envoy? de mon t?l?phone Android avec K-9 Mail. Excusez la bri?vet?. From fweimer at redhat.com Tue Nov 11 10:35:22 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 11 Nov 2014 11:35:22 +0100 Subject: JEP 223: New Version-String Scheme In-Reply-To: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> Message-ID: <5461E66A.3020701@redhat.com> On 11/04/2014 11:05 PM, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/223 Downstreams may have to add additional, out-of-cycle security fixes. Should they avoid changing the version-string altogether if they do this? -- Florian Weimer / Red Hat Product Security From iris.clark at oracle.com Fri Nov 14 20:37:29 2014 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 14 Nov 2014 12:37:29 -0800 (PST) Subject: JEP 223: New Version-String Scheme In-Reply-To: <545CD83D.2030001@oracle.com> References: <545CBD6F.90708@oracle.com> <545CD83D.2030001@oracle.com> Message-ID: <0374a1af-d2a1-40e3-b7ea-c912ed052ab8@default> Hi, Magnus. Thank you so much for your comments. I apologize for the delay in replying. I'm still recovering from recent IT changes. I hoping that I've gotten past the worst bits. Let me answer the easy message first. > Am I correct in understanding that if once a 9.9.1 released, then 9.10.0 could never be released (since that would mean breaking the rule of monotonically incrementing security numbers)? No. Given versions 9.9.1, and 9.10.0, you can say is that 9.9.1 is more secure and has fewer features than 9.10.0. You can also say that 9.9.1 is "less than" 9.10.0 since version numbers are compared lexicographically. 9.10.0 can be released any time relative to 9.9.1. > I think the versioning scheme makes sense, but this situation is perhaps not completely intuitive, and could perhaps be expanded upon in either the JEP or in any other resulting document that will describe the new version system. I'm working to add text to the JEP to provide more details around ordering. As I work through those changes, I'll be working out a reply to your other message. Thanks, iris -----Original Message----- From: Magnus Ihse Bursie Sent: Friday, November 07, 2014 6:34 AM To: platform-jep-discuss at openjdk.java.net Subject: Re: JEP 223: New Version-String Scheme On 2014-11-07 13:39, Magnus Ihse Bursie wrote: > 3) Using a different marker than "-" for introducing $OPT, e.g. > underscore. > > For instance, 9.0.0_foo-opt or 9.0.0-ea-_foo-opt. I think this is a > better solution than the ones above, but it is not ideal. It also > differs from the semantic versioning rules. Correction; my example was intented to be " 9.0.0-ea_foo-opt". Also, I'd like to make sure I understand the exampel given in the JEP: > The sequence of numerals in a version number is compared to another > such sequence in numerical, pointwise fashion; /e.g./, |9.9.1| is less > than |9.10.0|. Am I correct in understanding that if once a 9.9.1 released, then 9.10.0 could never be released (since that would mean breaking the rule of monotonically incrementing security numbers)? But if 9.10.0 was released directly after 9.9.0, then later on 9.9.1 could be released. So this means that while 9.10.0 is in some way "newer" since the minor version is higher, it is also "older" in that it was released cronologically earlier, and does not contain the newest security fixes. I think the versioning scheme makes sense, but this situation is perhaps not completely intuitive, and could perhaps be expanded upon in either the JEP or in any other resulting document that will describe the new version system. Maybe what I'm getting at is some kind of discussion on the semantic meaning of ordering two version strings, not just technical discussions on how such ordering is to be achieved. /Magnus From iris.clark at oracle.com Fri Nov 14 20:37:31 2014 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 14 Nov 2014 12:37:31 -0800 (PST) Subject: JEP 223: New Version-String Scheme In-Reply-To: <5461E66A.3020701@redhat.com> References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> <5461E66A.3020701@redhat.com> Message-ID: 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? It's possible that a Project Lead may wish to coordinate version numbers, but I don't see why it couldn't be changed. Perhaps I've misunderstood the question? Thanks, iris From fweimer at redhat.com Fri Nov 14 21:38:11 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 14 Nov 2014 22:38:11 +0100 Subject: JEP 223: New Version-String Scheme In-Reply-To: References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> <5461E66A.3020701@redhat.com> Message-ID: <54667643.5000305@redhat.com> 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 From iris.clark at oracle.com Mon Nov 17 21:53:49 2014 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 17 Nov 2014 13:53:49 -0800 (PST) Subject: JEP 223: New Version-String Scheme In-Reply-To: <54667643.5000305@redhat.com> References: <20141104220533.9EA9D40C9A@eggemoggin.niobe.net> <5461E66A.3020701@redhat.com> <54667643.5000305@redhat.com> Message-ID: <961dc829-1769-4bfe-b5c8-58bed8407645@default> Hi, Florian. Thanks for the clarification. Since situation you describe is getting into binary release policy, I can only provide options for how the new version-string scheme could be used by downstream consumers of the JDK code base (including Oracle). Ultimately, the decision of what binary releases use to identify their release is at the discretion of the entity shipping the binary release. > 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 In no particular order, here are some choices. - Continue using the existing alternate version identification method. In your case it sounds like you could continue to not update the version number and rely on external metadata for accurate version identification. - Use the version number: Each downstream consumer could assign specific meaning to the fourth and later version number elements. For instance, Red Hat could decide that for their releases, element four is defined as $RHSECURITY with an increment policy that matches $SECURITY (or not). If upstream ships 9.0.1 and Red Hat has need to ship with additional security fixes prior to 9.0.2, the release number could be 9.0.1.1. I don't see a problem if another downstream consumer ships a slightly different release with an identical version number, just use System.getProperty("java.vendor") to distinguish them. - Use the version string: Each downstream consumer could encode additional information in $OPT. (Be careful because the JEP specifies that the value of $OPT is ignored when comparing two version strings.) - Coordinate an upstream release with an incremented $SECURITY containing the changes. This is perhaps the highest overhead solution, but it is what Oracle has done historically and will likely continue doing. Other downstream consumers could choose to do the same. There are other options. Remember that the JEP defines how a JDK version string will be represented in the OpenJDK source. A binary distribution is free to extend or completely alter this representation to suit their needs. Regards, iris -----Original Message----- From: Florian Weimer [mailto:fweimer at redhat.com] Sent: Friday, November 14, 2014 1:38 PM To: Iris Clark; platform-jep-discuss at openjdk.java.net Subject: Re: JEP 223: New Version-String Scheme 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 From mark.reinhold at oracle.com Wed Nov 19 16:36:04 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 19 Nov 2014 08:36:04 -0800 (PST) Subject: JEP 230: Microbenchmark Suite Message-ID: <20141119163604.3D98E43172@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/230 - Mark