Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)
Thanks for the explanation. So I think I’ll just leave it as is. New webrev: http://cr.openjdk.java.net/~tonyp/8207849/webrev.1/ The only new changes are in the spec.gmk.in file. Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On July 19, 2018 at 4:01:14 PM, Erik Joelsson (erik.joels...@oracle.com) wrote: On 2018-07-19 12:52, Tony Printezis wrote: Erik, Many thanks for looking at this change! I can totally add the VERSION_EXTRAX variables to the spec.gmk file. Related: I was not sure what to do with VERSION_NUMBER_ALL_POSITIONS. Right now, VERSION_NUMBER_FOUR_POSITIONS is exposed to the spec.gmk file but I'm not sure exactly where it’s used. Is it worth also exposing VERSION_NUMBER_ALL_POSITIONS? I didn’t to make sure that anything that relies on VERSION_NUMBER_FOUR_POSITIONS having exactly four numbers didn’t break (and I’m happy to leave it as is). The VERSION_NUMBER_FOUR_POSITIONS is used in windows launcher manifests (shows up if you right click a windows executable) and it's used internally at Oracle for Windows installers. I believe (but is not 100% sure) that the format with 4 numbers is specifically needed in the windows manifest case. /Erik Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On July 19, 2018 at 3:02:26 PM, Erik Joelsson (erik.joels...@oracle.com) wrote: Hello Tony, I think this looks ok. We like to keep AC_SUBST calls paired with variables in spec.gmk.in so please add corresponding VERSION_EXTRAX variables there. /Erik On 2018-07-19 11:46, Tony Printezis wrote: > Hi all, > > Here’s the webrev for this: > > http://cr.openjdk.java.net/~tonyp/8207849/webrev.0/ > > I’m no configure expert so I basically did a cut-and-paste of what was > already there. If there’s a way to do this better (maybe, cut down on the > awkward code replication), let let me know. > > The decision to allow up to 3 extra numbers was arbitrary. I can do more or > fewer. > > Tony > > — > Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)
Erik, Many thanks for looking at this change! I can totally add the VERSION_EXTRAX variables to the spec.gmk file. Related: I was not sure what to do with VERSION_NUMBER_ALL_POSITIONS. Right now, VERSION_NUMBER_FOUR_POSITIONS is exposed to the spec.gmk file but I'm not sure exactly where it’s used. Is it worth also exposing VERSION_NUMBER_ALL_POSITIONS? I didn’t to make sure that anything that relies on VERSION_NUMBER_FOUR_POSITIONS having exactly four numbers didn’t break (and I’m happy to leave it as is). Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On July 19, 2018 at 3:02:26 PM, Erik Joelsson (erik.joels...@oracle.com) wrote: Hello Tony, I think this looks ok. We like to keep AC_SUBST calls paired with variables in spec.gmk.in so please add corresponding VERSION_EXTRAX variables there. /Erik On 2018-07-19 11:46, Tony Printezis wrote: > Hi all, > > Here’s the webrev for this: > > http://cr.openjdk.java.net/~tonyp/8207849/webrev.0/ > > I’m no configure expert so I basically did a cut-and-paste of what was > already there. If there’s a way to do this better (maybe, cut down on the > awkward code replication), let let me know. > > The decision to allow up to 3 extra numbers was arbitrary. I can do more or > fewer. > > Tony > > — > Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
Re: adding additional numbers to the Java version string
Hi Martin, Yes, we have also used the opt field too. However, if I understand the spec correctly, when doing version comparisons, the opt string is compared alphanumerically. So if you add any numbers to it, you have to plan ahead and pad with enough 0s to make sure the comparison works as expected. Given that the spec now allows extra numbers in the version string, it’d be good to be able to use that instead. Additionally, we want both compareTo() and compareToIgnoreOptional() to show our version as different to the upstream one it’s synced up to. And adding an extra number to the version string satisfies that too. Other folks might want this to behave differently, and that’s totally OK! But, the change I proposed will help anyone who has the above requirement. Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On July 19, 2018 at 1:30:40 PM, Martin Buchholz (marti...@google.com) wrote: At Google we use --with-version-opt to put in local version data - that works for us. --with-version-patch is also available for third party build use. On Thu, Jul 19, 2018 at 6:54 AM, Erik Joelsson wrote: > Since JEP 223 specifies an arbitrary length (something I had missed > before), I agree the build should support a few extra version numbers. > > /Erik > > > On 2018-07-18 13:22, Tony Printezis wrote: > >> Hi all, >> >> According to the Java version string spec (JEPs 223 and 322) the first >> part >> of the version string is a sequence of numbers separated by periods. The >> sequence can be of arbitrary length. However, in the OpenJDK configure >> scripts, the sequence length is fixed to exactly four numbers. >> >> For our internal builds we’d like to add at least one additional number to >> the version string. Is there any interest in a change to the scripts to >> allow that? >> >> I’ve prototyped this in a generic way (can add up to 3 additional numbers, >> called “extra1”, “extra2”, and “extra3”). These are set by passing >> --with-version-extra(1|2|3)=… to configure. If they are not set, the >> version string is of course exactly the same as it was before. I also >> changed the way the value of --with-version-string=… is parsed to be able >> to also extract the additional three numbers, if present. >> >> Would this be generally helpful? >> >> Tony >> >> — >> Tony Printezis | @TonyPrintezis | tprinte...@twitter.com >> > >
RFR: 8207849: Allow the addition of more number to the Java version string (S)
Hi all, Here’s the webrev for this: http://cr.openjdk.java.net/~tonyp/8207849/webrev.0/ I’m no configure expert so I basically did a cut-and-paste of what was already there. If there’s a way to do this better (maybe, cut down on the awkward code replication), let let me know. The decision to allow up to 3 extra numbers was arbitrary. I can do more or fewer. Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
Re: adding additional numbers to the Java version string
Hi Erik, Thanks for the response. I created: https://bugs.openjdk.java.net/browse/JDK-8207849 (infrastructure/build is the right component for this, right?) and I’ll post a webrev soon. Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On July 19, 2018 at 9:53:42 AM, Erik Joelsson (erik.joels...@oracle.com) wrote: Since JEP 223 specifies an arbitrary length (something I had missed before), I agree the build should support a few extra version numbers. /Erik On 2018-07-18 13:22, Tony Printezis wrote: > Hi all, > > According to the Java version string spec (JEPs 223 and 322) the first part > of the version string is a sequence of numbers separated by periods. The > sequence can be of arbitrary length. However, in the OpenJDK configure > scripts, the sequence length is fixed to exactly four numbers. > > For our internal builds we’d like to add at least one additional number to > the version string. Is there any interest in a change to the scripts to > allow that? > > I’ve prototyped this in a generic way (can add up to 3 additional numbers, > called “extra1”, “extra2”, and “extra3”). These are set by passing > --with-version-extra(1|2|3)=… to configure. If they are not set, the > version string is of course exactly the same as it was before. I also > changed the way the value of --with-version-string=… is parsed to be able > to also extract the additional three numbers, if present. > > Would this be generally helpful? > > Tony > > — > Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
adding additional numbers to the Java version string
Hi all, According to the Java version string spec (JEPs 223 and 322) the first part of the version string is a sequence of numbers separated by periods. The sequence can be of arbitrary length. However, in the OpenJDK configure scripts, the sequence length is fixed to exactly four numbers. For our internal builds we’d like to add at least one additional number to the version string. Is there any interest in a change to the scripts to allow that? I’ve prototyped this in a generic way (can add up to 3 additional numbers, called “extra1”, “extra2”, and “extra3”). These are set by passing --with-version-extra(1|2|3)=… to configure. If they are not set, the version string is of course exactly the same as it was before. I also changed the way the value of --with-version-string=… is parsed to be able to also extract the additional three numbers, if present. Would this be generally helpful? Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
