From mark.reinhold at oracle.com Wed Oct 11 16:59:38 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 11 Oct 2017 09:59:38 -0700 (PDT) Subject: Welcome to the JDK Project! Message-ID: <20171011165938.9DFE7D2571@eggemoggin.niobe.net> All subscribers to the jdk10-dev mailing list are now subscribed to this new list, jdk-dev. The Authors, Committers, and Reviewers of this Project [1] are those of the JDK 10 Project, as proposed [2]. For the moment, let's continue to use the existing jdk10/* repositories for the main line of JDK development. We'll cut over to a corresponding set of jdk/* repositories when they're ready, perhaps this weekend, at which time the jdk10/* repositories will become read-only. - Mark [1] http://openjdk.java.net/census#jdk [2] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html From mark.reinhold at oracle.com Wed Oct 11 17:17:10 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 11 Oct 2017 10:17:10 -0700 (PDT) Subject: Proposed schedule for JDK 18.3 Message-ID: <20171011171710.CE586D257D@eggemoggin.niobe.net> Here is a proposed schedule: 2017/12/14 Rampdown Phase One 2018/01/11 All Tests Run 2018/01/18 Rampdown Phase Two 2018/02/22 Final Release Candidate 2018/03/20 General Availability The milestone definitions are the same as for JDK 8 [1]. There's no "Feature Complete" milestone since, in the six-month model, every feature must be complete before it's integrated. The main development line is, in effect, always feature complete. The set of features in the release contains all, and only, those features that are integrated ahead of Rampdown Phase One. (What does it mean for a feature to be "complete"? I'll propose a detailed definition shortly. It'll be along the lines of what the milestone has always meant for past releases: A complete feature includes, at the very least, all necessary code, specification text, and unit tests.) Comments from JDK Committers are welcome, as are reasoned objections. If no such objections are raised by 18:00 UTC next Wednesday, 18 October, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] this will be adopted as the schedule for JDK 18.3 (or whatever we wind up calling it). - Mark [1] http://openjdk.java.net/projects/jdk8/milestones#definitions [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From volker.simonis at gmail.com Thu Oct 12 07:59:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 Oct 2017 00:59:18 -0700 Subject: Proposed schedule for JDK 18.3 In-Reply-To: <20171011171710.CE586D257D@eggemoggin.niobe.net> References: <20171011171710.CE586D257D@eggemoggin.niobe.net> Message-ID: On Wed, Oct 11, 2017 at 10:17 AM, wrote: > Here is a proposed schedule: > > 2017/12/14 Rampdown Phase One > 2018/01/11 All Tests Run > 2018/01/18 Rampdown Phase Two > 2018/02/22 Final Release Candidate > 2018/03/20 General Availability > > The milestone definitions are the same as for JDK 8 [1]. > > There's no "Feature Complete" milestone since, in the six-month model, > every feature must be complete before it's integrated. The main > development line is, in effect, always feature complete. The set of > features in the release contains all, and only, those features that > are integrated ahead of Rampdown Phase One. Hi Mark, does this mean that the jdk-18.3 repository will be created (i.e. forked) just before "Rampdown Phase One" is entered? What will be the working model after the fork of jdk-18.3? Will bug fixes for 18.3 have to go to jdk-dev first and then backported to jdk-18.3 or can they be pushed right into jdk-18.3? In the latter case, will there be an automatic integration process of fixes from jdk-18.3 into jdk-dev? Thanks, Volker > > (What does it mean for a feature to be "complete"? I'll propose a > detailed definition shortly. It'll be along the lines of what the > milestone has always meant for past releases: A complete feature > includes, at the very least, all necessary code, specification text, > and unit tests.) > > Comments from JDK Committers are welcome, as are reasoned objections. > If no such objections are raised by 18:00 UTC next Wednesday, 18 October, > or if they're raised and then satisfactorily answered, then per the JEP > 2.0 process proposal [2] this will be adopted as the schedule for JDK > 18.3 (or whatever we wind up calling it). > > > - Mark > > > [1] http://openjdk.java.net/projects/jdk8/milestones#definitions > [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Fri Oct 13 00:43:26 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Oct 2017 17:43:26 -0700 Subject: Proposed schedule for JDK 18.3 In-Reply-To: References: <20171011171710.CE586D257D@eggemoggin.niobe.net> Message-ID: <20171012174326.398881457@eggemoggin.niobe.net> 2017/10/12 0:59:18 -0700, volker.simonis at gmail.com: > On Wed, Oct 11, 2017 at 10:17 AM, mark.reinhold at oracle.com wrote: >> ... >> >> There's no "Feature Complete" milestone since, in the six-month model, >> every feature must be complete before it's integrated. The main >> development line is, in effect, always feature complete. The set of >> features in the release contains all, and only, those features that >> are integrated ahead of Rampdown Phase One. > > does this mean that the jdk-18.3 repository will be created (i.e. > forked) just before "Rampdown Phase One" is entered? Yes. > What will be the working model after the fork of jdk-18.3? Will bug > fixes for 18.3 have to go to jdk-dev first and then backported to > jdk-18.3 or can they be pushed right into jdk-18.3? In the latter > case, will there be an automatic integration process of fixes from > jdk-18.3 into jdk-dev? Given the shorter stabilization period there likely won't be time for every bug fix to percolate from the main line into the release repo, so I expect that some (most?) fixes will go directly into the release repo. We'll try to automate merges of such fixes back into the main line, as we did for JDK 9. - Mark From sean.coffey at oracle.com Fri Oct 13 08:25:29 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 13 Oct 2017 09:25:29 +0100 Subject: Proposed schedule for JDK 18.3 In-Reply-To: <20171012174326.398881457@eggemoggin.niobe.net> References: <20171011171710.CE586D257D@eggemoggin.niobe.net> <20171012174326.398881457@eggemoggin.niobe.net> Message-ID: <85e43d30-700d-87a8-496e-488b14ec73a6@oracle.com> > Given the shorter stabilization period there likely won't be time for > every bug fix to percolate from the main line into the release repo, so > I expect that some (most?) fixes will go directly into the release repo. > We'll try to automate merges of such fixes back into the main line, as > we did for JDK 9. I'm not sure if this is the best model to adopt. The JDK 8 Updates Project has been using a critical-request model for some time now. It works well. Before accepting a patch into an upcoming production release (stabilization forest), we know that the patch has been soaked in the mainline where EA binaries are available and where more test infrastructure/cycles might also be available. Pulling a patch from the mainline also reduces concerns about avoiding a possible regression in a future release if a patch gets accidentally dropped or doesn't get ported in time for the next JDK release (which would be less than 6 months away) Given the regular 6 monthly release cycle, I'm hoping the bar will be real high for acceptance of such patches into a release post ramp-down. Regards, Sean. On 13/10/2017 01:43, mark.reinhold at oracle.com wrote: > 2017/10/12 0:59:18 -0700, volker.simonis at gmail.com: >> On Wed, Oct 11, 2017 at 10:17 AM, mark.reinhold at oracle.com wrote: >>> ... >>> >>> There's no "Feature Complete" milestone since, in the six-month model, >>> every feature must be complete before it's integrated. The main >>> development line is, in effect, always feature complete. The set of >>> features in the release contains all, and only, those features that >>> are integrated ahead of Rampdown Phase One. >> does this mean that the jdk-18.3 repository will be created (i.e. >> forked) just before "Rampdown Phase One" is entered? > Yes. > >> What will be the working model after the fork of jdk-18.3? Will bug >> fixes for 18.3 have to go to jdk-dev first and then backported to >> jdk-18.3 or can they be pushed right into jdk-18.3? In the latter >> case, will there be an automatic integration process of fixes from >> jdk-18.3 into jdk-dev? > Given the shorter stabilization period there likely won't be time for > every bug fix to percolate from the main line into the release repo, so > I expect that some (most?) fixes will go directly into the release repo. > We'll try to automate merges of such fixes back into the main line, as > we did for JDK 9. > > - Mark From gnu.andrew at redhat.com Mon Oct 16 15:09:53 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 16 Oct 2017 16:09:53 +0100 Subject: Proposed schedule for JDK 18.3 In-Reply-To: <85e43d30-700d-87a8-496e-488b14ec73a6@oracle.com> References: <20171011171710.CE586D257D@eggemoggin.niobe.net> <20171012174326.398881457@eggemoggin.niobe.net> <85e43d30-700d-87a8-496e-488b14ec73a6@oracle.com> Message-ID: On 13 October 2017 at 09:25, Se?n Coffey wrote: >> Given the shorter stabilization period there likely won't be time for >> every bug fix to percolate from the main line into the release repo, so >> I expect that some (most?) fixes will go directly into the release repo. >> We'll try to automate merges of such fixes back into the main line, as >> we did for JDK 9. > > > I'm not sure if this is the best model to adopt. The JDK 8 Updates Project > has been > using a critical-request model for some time now. It works well. Before > accepting a > patch into an upcoming production release (stabilization forest), we know > that the > patch has been soaked in the mainline where EA binaries are available and > where > more test infrastructure/cycles might also be available. > > Pulling a patch from the mainline also reduces concerns about avoiding a > possible > regression in a future release if a patch gets accidentally dropped or > doesn't get ported > in time for the next JDK release (which would be less than 6 months away) > > Given the regular 6 monthly release cycle, I'm hoping the bar will be real > high for > acceptance of such patches into a release post ramp-down. > I agree that's a better model. However, what I wouldn't like to see copied from 8u is that these forked release branches aren't public e.g. we can't see 8u152 until it's pushed to the 8u tree. > Regards, > Sean. > > Regards, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mark.reinhold at oracle.com Wed Oct 18 22:42:29 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 18 Oct 2017 15:42:29 -0700 (PDT) Subject: JEP 311: Java Packager API & CLI Message-ID: <20171018224229.C0C7DEA64A@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/311 - Mark From mark.reinhold at oracle.com Thu Oct 19 15:08:36 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 19 Oct 2017 08:08:36 -0700 (PDT) Subject: Version-string schemes for the Java SE Platform and the JDK Message-ID: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> (This is a long note on a complex topic that's inherently difficult to discuss. If you wish to reply, please first read all the way through to the end.) In my proposal to adopt a strict six-month release cadence I suggested that, going forward, the version strings of feature releases be of the form $YEAR.$MONTH [1][2]. Thus next year's March release would be 18.3, the September release would be 18.9, and so on each year. Not everyone likes this proposal, which isn't surprising -- discussions of version-string schemes, much like those of language syntax, often tend to degenerate into bike-sheds [3][4]. That's due, in part, to the use of version strings -- across the software industry and for several decades now -- to encode multiple not-quite-orthogonal axes of information, which can answer different but often related questions: - Compatibility -- "Will my code break if I upgrade to this release?" - Significance -- "How different is this release from what I have now?" - Security -- "Does this release contain new security fixes?" - Support -- "For how long will this release be supported?" - Identity -- "On exactly which build was this bug reported against?" - Time -- "When did this release ship? How far behind am I?" Convention dictates that the principal part of a version string, i.e., the version number, be a sequence of numerals separated by period characters. (Let's ignore, for now, optional information such as pre-release status and build numbers.) Convention also dictates that version numbers be pointwise totally ordered, that they increase monotonically over time, and that the version number of a feature release be a prefix of the version numbers of its update releases. Given these conventions and a strict, time-based release cadence, which of the above axes are both important and appropriate to encode into version numbers? Which are practical to encode into version numbers? Which should have more weight, i.e., be encoded in the earlier numerals of version numbers, and which should have less weight, i.e., be encoded in the later numerals? Some considerations for each axis, in turn: - Compatibility is obviously important -- it's one of the core values of the Java Platform, after all -- but it's problematic in at least two respects and hence not a sound basis for version numbers. First: Compatibility is, itself, multi-dimensional and therefore difficult to encode into a simple sequence of numerals. What counts as an incompatible change? Some cases are obvious, e.g., a language change after which some old source files no longer compile, a JVM change after which some old class files are no longer valid, or an API change that removes an existing module, package, type, or element thereof. Many cases are, however, less than obvious, e.g., a language change after which some previously-rejected source files do compile, a bug fix that changes the element order of an array returned by an API, an enhancement that allows a command-line option to accept some previously-rejected arguments, or an optimization that removes an internal API. It might be practical to encode compatibility information into a two- or three-numeral version number for something as simple as a single library whose only interface with the outside world is its API [5]. It's far from clear how to do that, though, in a way that's easy for everyone to understand for something as complex as the Java Platform itself, and implementations thereof. Second: The compatibility of a particular release with any of its predecessors depends upon the set of features in that release. In a time-based release model, however, the set of features is not known until late in each release cycle, after the final feature is merged. This complicates discussions of any specific release and the tracking of changes in JIRA and related systems. If, e.g., we use the leading numerals of version numbers to encode compatibility in the usual way, with the first numeral increasing only when incompatible changes are made, then would the March 2018 release be version 9.1, or 10? We can't know until some time in December 2017, when the release closes for stabilization. We could address this problem by establishing secondary, time-based labels for releases, but that would be awkward and could lead to even more confusion. - Significance is even harder to measure than compatibility, and like compatibility it depends upon the set of features in a release and hence can't be known until late in a release cycle. The best we can do for significance is insist that, over time, differences in version numbers roughly reflect differences in release content. An increment of the first numeral of a version number should indicate a greater amount of change than increments of later numerals. - Security is important, but the security level can't be encoded in one of the earlier numerals of a version number since it evolves at a rate that's unpredictable relative to all the other axes and would therefore violate the monotonicity constraint. (JEP 223 [6] solved this problem by using the third numeral of a version number to record the security level of a release within a particular major-release family, resetting that number only at the next major release. That scheme was, however, designed under the assumption of multi-year major releases, each of which could have several simultaneous update-release lines. If security fixes are routinely delivered in one stream of update releases per feature release, as envisioned in this new model [7], then there's less reason to encode the security level in the version number.) - The support lifetime of a release is useful information, but it's not appropriate to encode that into the version number of the Java SE Platform or the JDK. The version number should be identical in all implementations of a given release, but the support lifetime of a release may vary from implementor to implementor. Oracle might choose, e.g., to offer support to its customers for twenty years on releases three years apart, but another implementor might offer support for ten years on releases two years apart. - Identity is important, especially for use in bug reports, but it need not be encoded in the version number itself. It's reasonable to ask that bug reports include the full version string, so it suffices to include a build identifier or other implementation information after the version number itself (e.g., 9+181, the full version string of JDK 9 GA). These considerations leave us with the final axis, time, as the leading candidate for the primary basis of Java SE and JDK version numbers. This would be a departure from past releases, in which we've used version numbers that roughly encode both compatibility and significance. It is, however, a better fit for a strict, time-based release model since the version number of any particular release is known well in advance. The compatibility level of a release would still be indicated by the length of its version number, since we'll continue our long-standing practice of making obviously-incompatible changes only in feature releases. The security level of an update release would, similarly, be reflected in its version number as a whole, since a later release will always contain more security fixes than its predecessor. The main remaining question, then, is that of how to encode time in version numbers: As an absolute value, derived from the date of the release, or as a relative value, measuring the amount of time since the previous release of the same type? In the abstract, absolute times have three attractive properties: - Absolute times reflect release dates, so they make it clear to all involved -- both developers of the JDK and users of the JDK -- that these are time-based releases. There can be no question of delaying a release in order to add "just one more feature" to it. - Absolute times make it easy to figure out how old a release is, so that as a user you can understand how far behind you are. Relative times require you to know what the time units are, and when these time-based version numbers were adopted. - Absolute times are independent of the release cadence. If in a few years we switch to an even faster cadence, say every three months, then an absolute scheme would need no change but a relative scheme would need to be revised with a new time unit and starting point. Now, at last, for some concrete alternatives: (A) Absolute: $YY$MM, padding the month number with a zero as needed, and $YY$MM.$AGE for update releases, where $AGE is the number of months since $YY$MM. (B) Absolute: $YY.$M as proposed, without padding the month number, and $YY.$M.$AGE for update releases, where $AGE is as above. (C) Relative: $N, where $N is the number of half-years since JDK 9 GA (September 2017) plus nine, and $N.$AGE for update releases, where $AGE is as above. ($AGE is more useful than another incrementing counter since it leaves room for emergency update releases without having to renumber subsequent update releases that are already in development.) Examples of these alternatives, for the next two feature releases and their first two update releases: (A) (B) (C) GA (March 2018) 1803 18.3 10 First update (April) 1803.1 18.3.1 10.1 Second update (July) 1803.4 18.3.4 10.4 GA (September 2018) 1809 18.9 11 First update (October) 1809.1 18.9.1 11.1 Second update (January) 1809.4 18.9.4 11.4 Some pros (+) and cons (-) of each alternative (some of these points are subjective, but so it goes with this topic): (A) $YY$MM, with $YY$MM.$AGE for updates (+) Has the three advantages of absolute times. (+) The `Runtime.Version` API introduced by JEP 223 can be adapted fairly easily. Code that parses raw version strings would need little or no change (as long as it already does so correctly!). (-) On the surface 1803 is an enormous leap from 9, is likely to cause confusion, and has connotations of being very old [8]. (B) $YY.$M, with $YY.$M.$AGE for updates (+) Has the three advantages of absolute times. (+) Similar to some other significant platforms, e.g., Ubuntu Linux, and less shocking in appearance than (A). (-) People unfamiliar with the scheme could conflate 18.3 and 18.9 as being minor releases of JDK 18, which isn't the case. There is some evidence of similar confusion around Ubuntu releases [9]. (-) The logical "major" version number is now a pair of numbers, year and month. We could mitigate this in the `Runtime.Version` API by encoding the year and month as $YY$MM in the existing major number, and adding new methods that return the year and month. Code that parses raw version strings will likely require change, including code not just in the JDK itself but in existing tools and CI systems [a]. (C) $N, with $N.$AGE for updates (+) The most straightforward and least-surprising option, and familiar from other rapidly-evolving projects such as Firefox and Chrome. (+) The `Runtime.Version` API can be adapted very easily, and code that (correctly) parses raw version strings would need no change. (-) Lacks the three advantages of absolute times. (-) If we ever switch to an even faster cadence then we could eventually have very large version numbers, as in (A). In the limit we could wind up in a situation like that of CoreOS, whose latest stable release is numbered 1520.6 [b]. These are three plausible alternatives; there are countless others, but I suspect that many if not most are minor variants of these three. To mention just two examples: - We could simplify our grandchildren's lives and represent the year with four digits rather than two. That would, however, lead to even longer version numbers. - We could zero-pad the month number in (B) so as to be exactly like Ubuntu ($YY.$MM) which might make it a bit more obvious that JDK 18.03 isn't an update release of JDK 18. This would only work, though, so long as we never ship a feature release after September in any particular year. (Ubuntu ships in April (04) and October (10), so zero-padding really only helps them half the time.) * * * If you've read this far, my question to you now is not the question that you might expect. Please don't say which version-number scheme you prefer for Java SE and the JDK. Instead, please only communicate any additional information that's relevant to the choice of such a scheme. In particular: - Are there additional pros and cons to the alternatives listed above? - Are there additional alternatives worth considering, and if so what are their pros and cons? - Are there specific experiences with other projects or products that can inform this choice? In order to discourage this from devolving into another version-numbering bike-shed discussion I'll give much greater weight to your first reply to this message than to any other, so please think and write carefully before you post. I'll also ignore replies-to-replies -- if you really want to argue with someone else about one scheme vs. another then I won't stop you, but I don't think that's a useful use of most readers' time. Finally, I'll heavily discount replies that quote more text from this message than add new text of their own, so please quote just the text that's actually needed to provide context for your reply. In a week or so I'll summarize any new information received, and then make a specific proposal. - Mark [1] https://mreinhold.org/blog/forward-faster [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html [3] http://bikeshed.org/ [4] https://wiki.haskell.org/Wadler's_Law [5] http://semver.org [6] http://openjdk.java.net/jeps/223 [7] https://mreinhold.org/blog/forward-faster#Proposal [8] https://en.wikipedia.org/wiki/1803 [9] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004429.html [a] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004352.html [b] https://coreos.com/releases From rschmitt at pobox.com Thu Oct 19 16:25:24 2017 From: rschmitt at pobox.com (Ryan Schmitt) Date: Thu, 19 Oct 2017 09:25:24 -0700 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: One common reason for discussions to devolve into bikeshedding is that they have become unmoored from any particular problem-solving activity, and discussion participants are much more anxious to express their subjective aesthetic judgements than to make careful engineering evaluations. You've laid out a very detailed explanation of the different considerations involved in designing a versioning scheme. However, Java already *has* a versioning scheme, as codified in JEP 223, and it is not self-evident why a six-month release train as opposed to a two-year release train would invalidate that scheme. So I would like to request clarification: what problem are you trying to solve? If we don't know what our problem-solving objective is, then we can't know if a particular proposal meets that objective or not, and then it doesn't matter how much information we sift through, our only basis for conversation will be bikeshedding. From david.lloyd at redhat.com Thu Oct 19 17:06:26 2017 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 19 Oct 2017 12:06:26 -0500 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: On Thu, Oct 19, 2017 at 10:08 AM, wrote: > to degenerate into bike-sheds [3][4]. Disagree. The bike-shed metaphor specifically relates to topics of great complexity, whose less-important side aspects (the bike shed) are debated rather than the core topic because few understand the core topic (the "atomic plant"). Version discussions don't fall into this category - quite the opposite actually: there are a vast number of people with fully informed background and experience on the core topic: as software engineers, most of us are building this particular atomic plant on a daily basis. OTOH if the release process is the atomic plant, then surely the idea of changing the release numbering was a bikeshed topic to begin with, and it should have been left as-is. > axes of information, which can answer different but often related questions: I would add these axes, which are frankly typically the only two that my users normally ever seem to care about: - Order -- "Did this version come before or after that one?" This is a separate issue from "Time", which is a special case of "Order". - Sequence -- "What versions came immediately before or after this one? If my fix doesn't get into this release, what is my next chance? How many versions between this one and that one?" > Convention also dictates that version numbers be pointwise totally ordered, that they increase monotonically over time This is less of a convention and more of a hard requirement that speaks to the definition of what "version" even means. Syntax aside, versions really *must* be totally ordered or they are meaningless: machines cannot really make much use of them, nor can humans, beyond basic identity comparisons. > Some considerations for each axis, in turn: >[...] > These considerations leave us with the final axis, time, as the leading > candidate for the primary basis of Java SE and JDK version numbers. Due to neglect of the other two axes I mention above, I challenge this conclusion. Also, even without the aforementioned additional axes, I would argue that there would still be no logical demand to use the remaining axis as the primary basis for versioning. You *could* do it, but there seems to be no logical path that would say you *must* do it. > In the abstract, absolute times have three attractive properties: > - Absolute times reflect release dates, so they make it clear to all > involved -- both developers of the JDK and users of the JDK -- that > these are time-based releases. There can be no question of delaying > a release in order to add "just one more feature" to it. This brings to mind the famous quote attributed to Stroustrup regarding technical solutions to social problems. There should never be a question of delaying a release: this is because the release manager says "This release will not be delayed". If you're at a stage where the version number is the pivotal argument to prevent this, then I'd say there is a broken process that needs to be amended, because experience tells me that if the delay mentality exists, it will surface regardless of this (or really any) type of consequence. If date-based version numbers are used, if/when the social contract is violated such that a release goes out when it shouldn't (either late or early), you end up either with an inconsistent date/version (if the version is chosen based on the actual release date) or a version number which is just plain wrong (if the version does not match the incorrect release date). Using simple sequential numbers means that if/when the human process is broken, the technical result (which is enshrined for eternity) will still be self-consistent and correct. Also, this problem's relevance is generally limited to those who contribute to the JDK, whereas the users of the JDK's version scheme are primarily not JDK contributors, likely by a ratio of at least 1,000:1 (if not more). > - Absolute times make it easy to figure out how old a release is, so > that as a user you can understand how far behind you are. The most useful answer to the question of "how far behind am I?" is usually not a number of months or years, but a number of releases. Or sometimes, a set of features missed, which is also a function of the number of releases, not the amount of calendar time. > eventually have very large version numbers, as in (A). In the >[...] > latest stable release is numbered 1520.6 [b]. As an aside, it's not clear why "very large" version numbers would themselves be any sort of disadvantage or problem. We only care about the dates of those releases for historical or social reasons, not technical reasons. Using dates here (whether absolute or relative) obscures these bits of information without giving the user anything enduringly useful in return. > - Are there additional pros and cons to the alternatives listed above? The cons of using time at all are that that you get a semblance of order (if you stick with 4-digit years, grandkids or not!) but no idea of sequence. The question of "when was this release cut?" is not nearly as frequently asked as "what release came before/after X?" or "how many releases different am I?". > - Are there additional alternatives worth considering, and if so what > are their pros and cons? A plain sequence starting from 10 and counting up with each primary release, not encoding any date information. Pros: sequence, order, consistency with the current scheme, not confusing to users, consistency with the majority of existing software, compatibility and consistency with JPMS and most other existing version schemes, general predictability (based on cadence) approximately when a release will appear or has appeared without resorting to difficult things like Google Cons: inability to use the version scheme as a social lever over the JDK release manager, extra work to look up the exact date when a release was or will be performed if one cares about that information > - Are there specific experiences with other projects or products that > can inform this choice? The vast majority of software in existence (including the JDK itself) uses a monotonically and sequentially increasing primary version with success. The costs and risks of revisiting this choice with a novel scheme at this time seem to outweigh the benefits to me. -- - DML From gnu.andrew at redhat.com Thu Oct 19 18:29:56 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 19 Oct 2017 19:29:56 +0100 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: On 19 October 2017 at 16:08, wrote: snip... > > Examples of these alternatives, for the next two feature releases and > their first two update releases: > > (A) (B) (C) > GA (March 2018) 1803 18.3 10 > First update (April) 1803.1 18.3.1 10.1 > Second update (July) 1803.4 18.3.4 10.4 > GA (September 2018) 1809 18.9 11 > First update (October) 1809.1 18.9.1 11.1 > Second update (January) 1809.4 18.9.4 11.4 > I have a slight preference for one over the other - and would prefer a clean break with the past - but these are similar for the most part. My main concern is with how the Long-Term Support (LTS) releases fit into this picture. For this, we need to move further forward than the first short-term release and the first LTS release in September 2018. I've used scheme B, and assumed that the security macro number is increasing by three, to allow space for unscheduled updates. GA (March 2019): Release of 19.3.0 First update (April 2019): Release of 19.3.1 *and* 18.9.7. Second update (July 2019): Release of 19.3.4 and 18.9.10 Now, with 19.3.0, the version is greater than 18.9.4, but they are of the same security status. Our first issue comes in April 2019, when 18.9.7 is now more secure than 19.3.0, but 19.3.0 has the greater version number. Similarly, in July 2019, 19.3.0 and 19.3.1 will be less secure than 18.9.10. This was true before, with e.g. 7u141 having security fixes that weren't in 8u121, for example, but there was also a clearer separation between a major version and updates for it. I guess my point is that there's nothing immediately clear about a version like 18.9.x that says it should be treated differently to 18.3.x, 19.3.x, 19.9.x and so on. Indeed, there are going to be updates to major version 18 that are more up-to-date with security fixes than any release of major version 19 or 20, the next LTS release being 21.9. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From ben at panderalabs.com Thu Oct 19 19:42:48 2017 From: ben at panderalabs.com (Ben Madore) Date: Thu, 19 Oct 2017 19:42:48 +0000 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: On 19 October 2017 at 16:08, wrote: > (A) Absolute: $YY$MM, padding the month number with a zero as needed, > and $YY$MM.$AGE for update releases, where $AGE is the number of > months since $YY$MM. > > (B) Absolute: $YY.$M as proposed, without padding the month number, > and $YY.$M.$AGE for update releases, where $AGE is as above. > > (C) Relative: $N, where $N is the number of half-years since JDK 9 GA > (September 2017) plus nine, and $N.$AGE for update releases, where > $AGE is as above. ($AGE is more useful than another incrementing > counter since it leaves room for emergency update releases without > having to renumber subsequent update releases that are already in > development.) > > Examples of these alternatives, for the next two feature releases and > their first two update releases: > > Examples of these alternatives, for the next two feature releases and > their first two update releases: > > (A) (B) (C) > GA (March 2018) 1803 18.3 10 > First update (April) 1803.1 18.3.1 10.1 > Second update (July) 1803.4 18.3.4 10.4 > GA (September 2018) 1809 18.9 11 > First update (October) 1809.1 18.9.1 11.1 > Second update (January) 1809.4 18.9.4 11.4 > What is the convention if multiple releases have to occur more frequently than the resolution of $AGE. That is, a month. For instance if release the first update to 18.3 is 18.3.1 what happens if immediately upon release a major regression is found? This could not be 18.3.2 - unless it was artificially held to be released in May. Would it be 18.3.1.1? -Ben From mik3hall at gmail.com Thu Oct 19 21:11:52 2017 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Oct 2017 16:11:52 -0500 Subject: JEP 311: Java Packager API & CLI Message-ID: It was recently indicated on the javafx list that questions concerning this subject and JEP 311 should be posted to this list. I guess my first question then would be, is the assumption correct that support for Java Packager will now be on this list? The second question to the JEP is that I don?t see that it includes --add-exports listed with the supported JEP arguments. My understanding is that this might sometimes be needed for restricted/not visible API?s with the current release of Java 9? From kevin.rushforth at oracle.com Thu Oct 19 21:23:06 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Oct 2017 14:23:06 -0700 Subject: JEP 311: Java Packager API & CLI In-Reply-To: References: Message-ID: <59E917BA.606@oracle.com> Michael Hall wrote: > It was recently indicated on the javafx list that questions concerning this subject and JEP 311 should be posted to this list. > > I guess my first question then would be, is the assumption correct that support for Java Packager will now be on this list? > The javapackager was originally the "javafxpackager", but as it is no longer specific to JavaFX it makes more sense to discuss it here. The code base is still in the openjfx repo, but it seems better to do reviews on this more general list. > The second question to the JEP is that I don?t see that it includes --add-exports listed with the supported JEP arguments. > My understanding is that this might sometimes be needed for restricted/not visible API?s with the current release of Java 9? > I'll let Victor or others chime in about this, but it seems that providing some support for --add-exports might be useful. -- Kevin From victor.drozdov at oracle.com Thu Oct 19 21:31:21 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Thu, 19 Oct 2017 14:31:21 -0700 Subject: JEP 311: Java Packager API & CLI In-Reply-To: <59E917BA.606@oracle.com> References: <59E917BA.606@oracle.com> Message-ID: Hello, On 10/19/17 2:23 PM, Kevin Rushforth wrote: > > Michael Hall wrote: >> It was recently indicated on the javafx list that questions >> concerning this subject and JEP 311 should be posted to this list. >> >> I guess my first question then would be, is the assumption correct >> that support for Java Packager will now be on this list? > > The javapackager was originally the "javafxpackager", but as it is no > longer specific to JavaFX it makes more sense to discuss it here. The > code base is still in the openjfx repo, but it seems better to do > reviews on this more general list. > >> The second question to the JEP is that I don?t see that it includes >> --add-exports listed with the supported JEP arguments. My >> understanding is that this might sometimes be needed for >> restricted/not visible API?s with the current release of Java 9? > > I'll let Victor or others chime in about this, but it seems that > providing some support for --add-exports might be useful. Initially we didn't plan to add new modular arguments. I agree it might be useful, we will consider adding this as a part of this JEP or separate enhancement request. --Victor > > -- Kevin > From mandy.chung at oracle.com Thu Oct 19 21:36:25 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 19 Oct 2017 14:36:25 -0700 Subject: JEP 311: Java Packager API & CLI In-Reply-To: <59E917BA.606@oracle.com> References: <59E917BA.606@oracle.com> Message-ID: On 10/19/17 2:23 PM, Kevin Rushforth wrote: > > Michael Hall wrote: >> It was recently indicated on the javafx list that questions >> concerning this subject and JEP 311 should be posted to this list. >> >> I guess my first question then would be, is the assumption correct >> that support for Java Packager will now be on this list? > > The javapackager was originally the "javafxpackager", but as it is no > longer specific to JavaFX it makes more sense to discuss it here. The > code base is still in the openjfx repo, but it seems better to do > reviews on this more general list. > >> The second question to the JEP is that I don?t see that it includes >> --add-exports listed with the supported JEP arguments. My >> understanding is that this might sometimes be needed for >> restricted/not visible API?s with the current release of Java 9? > > I'll let Victor or others chime in about this, but it seems that > providing some support for --add-exports might be useful. |As --add-exports is a JVM option, I assume it can be passed to -jvmargs||? Mandy | From mik3hall at gmail.com Thu Oct 19 21:37:06 2017 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Oct 2017 16:37:06 -0500 Subject: JEP 311: Java Packager API & CLI In-Reply-To: References: <59E917BA.606@oracle.com> Message-ID: <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> > On Oct 19, 2017, at 4:31 PM, victor.drozdov at oracle.com wrote: > > Hello, > > On 10/19/17 2:23 PM, Kevin Rushforth wrote: >> >> Michael Hall wrote: >>> It was recently indicated on the javafx list that questions concerning this subject and JEP 311 should be posted to this list. >>> >>> I guess my first question then would be, is the assumption correct that support for Java Packager will now be on this list? >> >> The javapackager was originally the "javafxpackager", but as it is no longer specific to JavaFX it makes more sense to discuss it here. The code base is still in the openjfx repo, but it seems better to do reviews on this more general list. >> >>> The second question to the JEP is that I don?t see that it includes --add-exports listed with the supported JEP arguments. My understanding is that this might sometimes be needed for restricted/not visible API?s with the current release of Java 9? >> >> I'll let Victor or others chime in about this, but it seems that providing some support for --add-exports might be useful. > Initially we didn't plan to add new modular arguments. I agree it might be useful, we will consider adding this as a part of this JEP or separate enhancement request. Thanks. I couldn?t figure out how to use it with the current javapackager. It turned out I needed ?add-modules, I?m new to modular concerns. This was for JShell. It also seemed that this needed a java executable in the bin directory. I added that manually and was able to use JShell from a OS X java 9 application. I?m not sure if the bin directory would be something the JEP would also consider? From mik3hall at gmail.com Thu Oct 19 21:56:37 2017 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Oct 2017 16:56:37 -0500 Subject: JEP 311: Java Packager API & CLI In-Reply-To: References: <59E917BA.606@oracle.com> Message-ID: <61A5AAE0-4C3C-4256-AA6E-D24378120F8E@gmail.com> > On Oct 19, 2017, at 4:36 PM, mandy chung wrote: > > > > On 10/19/17 2:23 PM, Kevin Rushforth wrote: >> >> Michael Hall wrote: >>> It was recently indicated on the javafx list that questions concerning this subject and JEP 311 should be posted to this list. >>> >>> I guess my first question then would be, is the assumption correct that support for Java Packager will now be on this list? >>> >> >> The javapackager was originally the "javafxpackager", but as it is no longer specific to JavaFX it makes more sense to discuss it here. The code base is still in the openjfx repo, but it seems better to do reviews on this more general list. >> >>> The second question to the JEP is that I don?t see that it includes --add-exports listed with the supported JEP arguments. My understanding is that this might sometimes be needed for restricted/not visible API?s with the current release of Java 9? >>> >> >> I'll let Victor or others chime in about this, but it seems that providing some support for --add-exports might be useful. > > As --add-exports is a JVM option, I assume it can be passed to -jvmargs? As indicated I couldn?t figure out how to get javapackager to pass this argument. But I am not that familiar with javapackager either so it?s possible I didn?t do this correctly. From mark.reinhold at oracle.com Thu Oct 19 22:49:52 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 19 Oct 2017 15:49:52 -0700 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: <20171019154952.389881313@eggemoggin.niobe.net> 2017/10/19 9:25:24 -0700, Ryan Schmitt : > One common reason for discussions to devolve into bikeshedding is that they > have become unmoored from any particular problem-solving activity, and > discussion participants are much more anxious to express their subjective > aesthetic judgements than to make careful engineering evaluations. You've > laid > out a very detailed explanation of the different considerations involved in > designing a versioning scheme. However, Java already *has* a versioning > scheme, > as codified in JEP 223, and it is not self-evident why a six-month release > train as opposed to a two-year release train would invalidate that scheme. > So I > would like to request clarification: what problem are you trying to solve? It's so simple to state that I supposed it was obvious: Given the new release model, what is the best version scheme for the Java SE Platform and the JDK? Shifting from an irregular multi-year cadence to a strict time-based cadence is a big change, so it's worth asking the question. Perhaps the scheme defined in JEP 223, which can be seen as a variant of alternative (C), is best -- but perhaps there's something better. - Mark From victor.drozdov at oracle.com Thu Oct 19 23:07:35 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Thu, 19 Oct 2017 16:07:35 -0700 Subject: JEP 311: Java Packager API & CLI In-Reply-To: <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> References: <59E917BA.606@oracle.com> <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> Message-ID: <0e7cb475-1b2e-a33b-e29b-666162e759b7@oracle.com> > >> On Oct 19, 2017, at 4:31 PM, victor.drozdov at oracle.com >> wrote: >> >> Hello, >> >> On 10/19/17 2:23 PM, Kevin Rushforth wrote: >>> >>> Michael Hall wrote: >>>> It was recently indicated on the javafx list that questions >>>> concerning this subject and JEP 311 should be posted to this list. >>>> >>>> I guess my first question then would be, is the assumption correct >>>> that support for Java Packager will now be on this list? >>> >>> The javapackager was originally the "javafxpackager", but as it is >>> no longer specific to JavaFX it makes more sense to discuss it here. >>> The code base is still in the openjfx repo, but it seems better to >>> do reviews on this more general list. >>> >>>> The second question to the JEP is that I don?t see that it includes >>>> --add-exports listed with the supported JEP arguments. My >>>> understanding is that this might sometimes be needed for >>>> restricted/not visible API?s with the current release of Java 9? >>> >>> I'll let Victor or others chime in about this, but it seems that >>> providing some support for --add-exports might be useful. >> Initially we didn't plan to add new modular arguments. I agree it >> might be useful, we will consider adding this as a part of this JEP >> or separate enhancement request. > > Thanks. I couldn?t figure out how to use it with the current > javapackager. It turned out I needed ?add-modules, I?m new to modular > concerns. > This was for JShell. It also seemed that this needed a java executable > in the bin directory. I added that manually and was able to use JShell > from a OS X java 9 application. > I?m not sure if the bin directory would be something the JEP would > also consider? If you need bin/java, you can add "-Bstrip-native-commands=false" (for JDK9). For the new CLI probably it will be "--strip-native-commands false"). --Victor > > From mik3hall at gmail.com Thu Oct 19 23:09:23 2017 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Oct 2017 18:09:23 -0500 Subject: JEP 311: Java Packager API & CLI In-Reply-To: <0e7cb475-1b2e-a33b-e29b-666162e759b7@oracle.com> References: <59E917BA.606@oracle.com> <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> <0e7cb475-1b2e-a33b-e29b-666162e759b7@oracle.com> Message-ID: > On Oct 19, 2017, at 6:07 PM, victor.drozdov at oracle.com wrote: > > >> >>> On Oct 19, 2017, at 4:31 PM, victor.drozdov at oracle.com wrote: >>> >>> Hello, >>> >>> On 10/19/17 2:23 PM, Kevin Rushforth wrote: >>>> >>>> Michael Hall wrote: >>>>> It was recently indicated on the javafx list that questions concerning this subject and JEP 311 should be posted to this list. >>>>> >>>>> I guess my first question then would be, is the assumption correct that support for Java Packager will now be on this list? >>>> >>>> The javapackager was originally the "javafxpackager", but as it is no longer specific to JavaFX it makes more sense to discuss it here. The code base is still in the openjfx repo, but it seems better to do reviews on this more general list. >>>> >>>>> The second question to the JEP is that I don?t see that it includes --add-exports listed with the supported JEP arguments. My understanding is that this might sometimes be needed for restricted/not visible API?s with the current release of Java 9? >>>> >>>> I'll let Victor or others chime in about this, but it seems that providing some support for --add-exports might be useful. >>> Initially we didn't plan to add new modular arguments. I agree it might be useful, we will consider adding this as a part of this JEP or separate enhancement request. >> >> Thanks. I couldn?t figure out how to use it with the current javapackager. It turned out I needed ?add-modules, I?m new to modular concerns. >> This was for JShell. It also seemed that this needed a java executable in the bin directory. I added that manually and was able to use JShell from a OS X java 9 application. >> I?m not sure if the bin directory would be something the JEP would also consider? > If you need bin/java, you can add "-Bstrip-native-commands=false" (for JDK9). For the new CLI probably it will be "--strip-native-commands false?). Thanks, I will give that a try. From Alan.Bateman at oracle.com Fri Oct 20 06:51:10 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Oct 2017 07:51:10 +0100 Subject: JEP 311: Java Packager API & CLI In-Reply-To: <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> References: <59E917BA.606@oracle.com> <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> Message-ID: On 19/10/2017 22:37, Michael Hall wrote: > : > Thanks. I couldn?t figure out how to use it with the current javapackager. It turned out I needed ?add-modules, I?m new to modular concerns. > This was for JShell. It also seemed that this needed a java executable in the bin directory. I added that manually and was able to use JShell from a OS X java 9 application. > I realize this is going off-topic but can you elaborate more on this. There should never be a need to copy binaries into the bin directory. The jdk.jshell module includes `jshell` launcher for example. -Alan. From mik3hall at gmail.com Fri Oct 20 08:29:07 2017 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 20 Oct 2017 03:29:07 -0500 Subject: JEP 311: Java Packager API & CLI In-Reply-To: References: <59E917BA.606@oracle.com> <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> Message-ID: > On Oct 20, 2017, at 1:51 AM, Alan Bateman wrote: > > On 19/10/2017 22:37, Michael Hall wrote: >> : >> Thanks. I couldn?t figure out how to use it with the current javapackager. It turned out I needed ?add-modules, I?m new to modular concerns. >> This was for JShell. It also seemed that this needed a java executable in the bin directory. I added that manually and was able to use JShell from a OS X java 9 application. >> > I realize this is going off-topic but can you elaborate more on this. There should never be a need to copy binaries into the bin directory. The jdk.jshell module includes `jshell` launcher for example. I got a JShell JRE with ?add-modules I initialize a JShell shell with? private static final JShell shell = JShell.create(); Without java in the bin directory the first time I try to use the shell with? List result = shell.eval(sb.toString()); for (SnippetEvent evt : result) { System.out.println(evt.value()); } I get? int x = 5 java.lang.ExceptionInInitializerError at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at org.cmdline.psuedoGestalt.Runner.invoke(Runner.java:207) at org.cmdline.psuedoGestalt.Runner.runStatic(Runner.java:234) at org.cmdline.psuedoGestalt.Runner.runMain(Runner.java:226) at org.cmdline.psuedoGestalt.Runner.run(Runner.java:144) Caused by: java.lang.IllegalStateException: Launching JShell execution engine threw: Failed remote listen: java.io.IOException: Cannot run program "/Users/mjh/HalfPipe/HalfPipe7.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java": error=2, No such file or directory @ com.sun.jdi.SocketListen (defaults: timeout=, port=, localAddress=) -- {timeout=timeout=5000, port=port=, localAddress=localAddress=127.0.0.1} at jdk.jshell/jdk.jshell.JShell.(JShell.java:139) at jdk.jshell/jdk.jshell.JShell$Builder.build(JShell.java:405) at jdk.jshell/jdk.jshell.JShell.create(JShell.java:420) at us.hall.repl.JShellReplImpl.(JShellReplImpl.java:8) ... 8 more Caused by: java.lang.InternalError: Failed remote listen: java.io.IOException: Cannot run program "/Users/mjh/HalfPipe/HalfPipe7.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java": error=2, No such file or directory @ com.sun.jdi.SocketListen (defaults: timeout=, port=, localAddress=) -- {timeout=timeout=5000, port=port=, localAddress=localAddress=127.0.0.1} at jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300) at jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:199) at jdk.jshell/jdk.jshell.execution.JdiInitiator.(JdiInitiator.java:111) at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103) at jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:148) at jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179) at jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:296) at jdk.jshell/jdk.jshell.execution.FailOverExecutionControlProvider.generate(FailOverExecutionControlProvider.java:103) at jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179) at jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:296) at jdk.jshell/jdk.jshell.JShell.(JShell.java:136) ... 11 more Caused by: java.io.IOException: Cannot run program "/Users/mjh/HalfPipe/HalfPipe7.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java": error=2, No such file or directory at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1128) at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071) at jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:173) ... 20 more Caused by: java.io.IOException: error=2, No such file or directory at java.base/java.lang.ProcessImpl.forkAndExec(Native Method) at java.base/java.lang.ProcessImpl.(ProcessImpl.java:339) at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:270) at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1107) ... 22 more From mik3hall at gmail.com Fri Oct 20 08:53:21 2017 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 20 Oct 2017 03:53:21 -0500 Subject: JEP 311: Java Packager API & CLI In-Reply-To: References: <59E917BA.606@oracle.com> <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> Message-ID: <6440281F-E18D-4E5F-B9E6-9951B04BB457@gmail.com> > On Oct 20, 2017, at 1:51 AM, Alan Bateman wrote: > > On 19/10/2017 22:37, Michael Hall wrote: >> : >> Thanks. I couldn?t figure out how to use it with the current javapackager. It turned out I needed ?add-modules, I?m new to modular concerns. >> This was for JShell. It also seemed that this needed a java executable in the bin directory. I added that manually and was able to use JShell from a OS X java 9 application. >> > I realize this is going off-topic but can you elaborate more on this. There should never be a need to copy binaries into the bin directory. The jdk.jshell module includes `jshell` launcher for example. Going back to this. You are saying that using the module launcher would of avoided the exceptions in my last post? Where is this documented? From Alan.Bateman at oracle.com Fri Oct 20 09:33:08 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Oct 2017 10:33:08 +0100 Subject: JEP 311: Java Packager API & CLI In-Reply-To: References: <59E917BA.606@oracle.com> <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> Message-ID: On 20/10/2017 09:29, Michael Hall wrote: >> On Oct 20, 2017, at 1:51 AM, Alan Bateman wrote: >> >> On 19/10/2017 22:37, Michael Hall wrote: >>> : >>> Thanks. I couldn?t figure out how to use it with the current javapackager. It turned out I needed ?add-modules, I?m new to modular concerns. >>> This was for JShell. It also seemed that this needed a java executable in the bin directory. I added that manually and was able to use JShell from a OS X java 9 application. >>> >> I realize this is going off-topic but can you elaborate more on this. There should never be a need to copy binaries into the bin directory. The jdk.jshell module includes `jshell` launcher for example. > I got a JShell JRE with ?add-modules > I initialize a JShell shell with? > private static final JShell shell = JShell.create(); > Without java in the bin directory the first time I try to use the shell with? > > List result = shell.eval(sb.toString()); > for (SnippetEvent evt : result) { > System.out.println(evt.value()); > } > > I get? > Someone more familiar with the packager would be in a better position to answer this. I suspect the issue is that packager is filtering out the java launcher as it expects the generated distribution to be only used to run one application. It doesn't know that adding jshell needs the java launcher. -Alan From mik3hall at gmail.com Fri Oct 20 09:38:21 2017 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 20 Oct 2017 04:38:21 -0500 Subject: JEP 311: Java Packager API & CLI In-Reply-To: References: <59E917BA.606@oracle.com> <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> Message-ID: > On Oct 20, 2017, at 4:33 AM, Alan Bateman wrote: > > > > On 20/10/2017 09:29, Michael Hall wrote: >>> On Oct 20, 2017, at 1:51 AM, Alan Bateman wrote: >>> >>> On 19/10/2017 22:37, Michael Hall wrote: >>>> : >>>> Thanks. I couldn?t figure out how to use it with the current javapackager. It turned out I needed ?add-modules, I?m new to modular concerns. >>>> This was for JShell. It also seemed that this needed a java executable in the bin directory. I added that manually and was able to use JShell from a OS X java 9 application. >>>> >>> I realize this is going off-topic but can you elaborate more on this. There should never be a need to copy binaries into the bin directory. The jdk.jshell module includes `jshell` launcher for example. >> I got a JShell JRE with ?add-modules >> I initialize a JShell shell with? >> private static final JShell shell = JShell.create(); >> Without java in the bin directory the first time I try to use the shell with? >> >> List result = shell.eval(sb.toString()); >> for (SnippetEvent evt : result) { >> System.out.println(evt.value()); >> } >> >> I get? >> > Someone more familiar with the packager would be in a better position to answer this. I suspect the issue is that packager is filtering out the java launcher as it expects the generated distribution to be only used to run one application. It doesn't know that adding jshell needs the java launcher. > > -Alan OK thanks, if the packager itself made this unnecessary that would be nice. I?m not sure how it would detect the dependency automatically, but possibly an option to indicate necessary bin executables by the user? I haven?t tried the earlier suggested parameter yet but I?m guessing that will give me a full set of bin commands when all I seem to need is java. From shade at redhat.com Fri Oct 20 10:34:11 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 20 Oct 2017 12:34:11 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: <93a23e27-5b03-0437-557e-22b66c19cab0@redhat.com> On 10/19/2017 05:08 PM, mark.reinhold at oracle.com wrote: > Not everyone likes this proposal, which isn't surprising -- discussions > of version-string schemes, much like those of language syntax, often tend > to degenerate into bike-sheds [3][4]. To be honest, changing the version scheme *again* looks like bike-shedding to me. We don't have to reinvent the version scheme that is already widely understood. Especially if the discussion about the version schemes does not indicate there exists the perfect one. > Some considerations for each axis, in turn: > > - Compatibility is obviously important -- it's one of the core values > of the Java Platform, after all -- but it's problematic in at least > two respects and hence not a sound basis for version numbers. > > First: Compatibility is, itself, multi-dimensional and therefore > difficult to encode into a simple sequence of numerals. What counts > as an incompatible change? I am baffled by this. JEP 223 explains what counts as $MAJOR change. Current version scheme puts compatibility on pedestal, and this dubs the project goals. We need more than "it would fit the process [a little] better" to switch from compatibility as major version axis. > Second: The compatibility of a particular release with any of its > predecessors depends upon the set of features in that release. In a > time-based release model, however, the set of features is not known > until late in each release cycle, after the final feature is merged. > This complicates discussions of any specific release and the tracking > of changes in JIRA and related systems. If, e.g., we use the leading > numerals of version numbers to encode compatibility in the usual way, > with the first numeral increasing only when incompatible changes are > made, then would the March 2018 release be version 9.1, or 10? We > can't know until some time in December 2017, when the release closes > for stabilization. This indicates the discrepancy in the release cadence proposal. If we incept the release without knowing what features go in there (which is in line with JEP process), we indeed cannot make a proper designation for that release early. But, this is not the version scheme problem, it is the circularity problem in the process itself, and that problem should be solved there. Switching to whatever versioning scheme that sweeps the process problem under the rug is odd. Is this the primary motivation for the version scheme change? If so, can we "just" amend the process with "jdkX"/"current"/"head"/"master"-like version that is not sealed until the release contents are finalized? It feels odd to extend the solution to "we need a name for a pending release that goes out in 6 months because we don't know what compat/security/etc label to apply" to "now we rename all released bits to not to have compat/security/etc labels, forever". In other words, if we have the the temporal problem with pending release, this does not mean we have to switch the versioning scheme for all stable releases. > These considerations leave us with the final axis, time, as the leading > candidate for the primary basis of Java SE and JDK version numbers. Not so fast! The rhetoric of the discussion seems to disqualify previous axes by listing their disadvantages. How is "time" axis exempt from the same scrutiny? The drawbacks seem to be is pretty much everything advantageous of previous axes -- which the discussion already recognizes as important: the encoding of basic compatibility data, basic notion of release significance, security patch level, identity, etc. > The main remaining question, then, is that of how to encode time in > version numbers: Since the rest of the post builds on the questionable premise that "time" is the agreed axis to base the versions on, it makes less sense to discuss that part in detail. It is important to get the basic ideas right, before spending precious time discussing the details. Thanks, -Aleksey From Alan.Bateman at oracle.com Fri Oct 20 10:59:12 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Oct 2017 11:59:12 +0100 Subject: JEP 311: Java Packager API & CLI In-Reply-To: References: <59E917BA.606@oracle.com> <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> Message-ID: <32fc7c84-b3b5-986a-4451-a9762d9e698e@oracle.com> On 20/10/2017 10:38, Michael Hall wrote: > > > OK thanks, if the packager itself made this unnecessary that would be > nice. I?m not sure how it would detect the dependency automatically, > but possibly an option to indicate necessary bin executables by the > user? I haven?t tried the earlier suggested parameter yet but I?m > guessing that will give me a full set of bin commands when all I seem > to need is java. > It's a good topic to bring up on the openjfx-dev mailing list. My personal view is that the packager should not do any stripping. -Alan. From neugens.limasoftware at gmail.com Fri Oct 20 12:57:03 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 20 Oct 2017 14:57:03 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: 2017-10-19 17:08 GMT+02:00 : Hi Mark, Thanks for bringing this to a broader discussion, it is very appreciated that you are involving the community. > If you've read this far, my question to you now is not the question that > you might expect. Please don't say which version-number scheme you > prefer for Java SE and the JDK. Instead, please only communicate any > additional information that's relevant to the choice of such a scheme. > In particular: > > - Are there additional pros and cons to the alternatives listed above? > > - Are there additional alternatives worth considering, and if so what > are their pros and cons? > > - Are there specific experiences with other projects or products that > can inform this choice? It is very difficult to participate without saying which version scheme one prefer... I think the important information of any release are: 1. Is an LTS? 2. Is a Security update? 3. Does it have the *latest* Security patches? I believe that those questions, especially the latter twos, are already addressed by the current scheme, while there's no information if we move solely on a time based visioning. For sequential updates we may be able to live with "always use the latest", but when they overlap wth LTS would make this understanding more complex. We can perhaps keep both worlds by adding the release date to the incremental version scheme if you really want, having an API that exposes it, like "10.0.1 (2018.05)", which clearly reads as "first security release of 10, released in May 2018". If the release date is all the important, that is. Eventually, especially in production systems, the LTS is going to be the version used the most, so I would humbly suggest to figure out a different version scheme that fits for the LTS first and then walk all the way down to the "regular" releases, if anything. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From victor.drozdov at oracle.com Fri Oct 20 19:38:57 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Fri, 20 Oct 2017 12:38:57 -0700 Subject: JEP 311: Java Packager API & CLI In-Reply-To: References: <59E917BA.606@oracle.com> <549E6F9C-3DE8-40D3-8FCB-8432C6607993@gmail.com> Message-ID: <3d6fbf93-3337-0a32-e4f3-623365c4c2f2@oracle.com> On 10/20/17 2:33 AM, Alan Bateman wrote: > > > On 20/10/2017 09:29, Michael Hall wrote: >>> On Oct 20, 2017, at 1:51 AM, Alan Bateman >>> wrote: >>> >>> On 19/10/2017 22:37, Michael Hall wrote: >>>> : >>>> Thanks. I couldn?t figure out how to use it with the current >>>> javapackager. It turned out I needed ?add-modules, I?m new to >>>> modular concerns. >>>> This was for JShell. It also seemed that this needed a java >>>> executable in the bin directory. I added that manually and was able >>>> to use JShell from a OS X java 9 application. >>>> >>> I realize this is going off-topic but can you elaborate more on >>> this. There should never be a need to copy binaries into the bin >>> directory. The jdk.jshell module includes `jshell` launcher for >>> example. >> I got a JShell JRE with ?add-modules >> I initialize a JShell shell with? >> private static final JShell shell = JShell.create(); >> Without java in the bin directory the first time I try to use the >> shell with? >> >> List result = shell.eval(sb.toString()); >> for (SnippetEvent evt : result) { >> System.out.println(evt.value()); >> } >> >> I get? >> > Someone more familiar with the packager would be in a better position > to answer this. I suspect the issue is that packager is filtering out > the java launcher as it expects the generated distribution to be only > used to run one application. It doesn't know that adding jshell needs > the java launcher. "bin" is filtered out by default because javapackager uses JNI to create JVM. There are args to include "bin" into the final app image. We may consider including "bin" by default or documenting this issue. --Victor > > -Alan From rfscholte at apache.org Sun Oct 22 13:49:45 2017 From: rfscholte at apache.org (Robert Scholte) Date: Sun, 22 Oct 2017 15:49:45 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: - Are there additional pros and cons to the alternatives listed above? The usage of yy cons is that in case we want another version scheme in the future (e.g. back to SemVer-like scheme) we will be block once we reach version 17. We should not assume that this will be the final switch of the versioning scheme. JEP223 only being applied for Java 9 is a good example. Assuming the year will be part of the scheme, I would advice to use yyyy as the *official* version. That should give us enough room to do version comparison by recognizing the first segment as a year instead of a major version. (18.x also looks like a semver, which should be avoided) Another con is that it is quite hard to recognize the LTS. I would prefer to have X. to be the LTS. That would imply that you could continue with the MM in the scheme. Assuming the version will start with the year, it might look like this: (D) GA (March 2018) 2018.03 First update (April) 2018.03.1 Second update (July) 2018.03.4 GA (September 2018) 2018.09 First update (October) 2018.09.1 Second update (January) 2018.09.4 GA (March 2019) 2018.15 (LTS) First update (April) 2018.15.1 Second update (July) 2018.15.4 GA (September 2019) 2019.09 First update (October) 2019.09.1 Second update (January) 2019.09.4 I'm also worried about the version as passed to different jdktools, like source/target/release. Its value is easy to link with a certain Java version and there are no gaps. Switching the a year-based version scheme would either lead to gaps or to an alias that doesn't match the Java Version (e.g. 10 for 18.3) thanks, Robert From dwfranken at gmail.com Sun Oct 22 17:15:08 2017 From: dwfranken at gmail.com (Dave Franken) Date: Sun, 22 Oct 2017 19:15:08 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: How about using a separate version number for internal and public usage? Internally, we can keep things semantic based on a more logical numbering starting with the current version, so just 9, 10 etc based on whatever is in the release. Publically we can use whatever we want, such as yyyy.mm. I think it's important to show the difference between LTS and non LTS, so I would just use yyyy for the LTS versions and yyyy.update for intermediate non LTS versions. SQL Server does this where SQL Server 2012 is 13.0 internally or something like that. And then you get R2 for an updated version. Windows also always had a different internal and public version number. Kind regards, Dave Franken Op 22 okt. 2017 15:50 schreef "Robert Scholte" : - Are there additional pros and cons to the alternatives listed above? The usage of yy cons is that in case we want another version scheme in the future (e.g. back to SemVer-like scheme) we will be block once we reach version 17. We should not assume that this will be the final switch of the versioning scheme. JEP223 only being applied for Java 9 is a good example. Assuming the year will be part of the scheme, I would advice to use yyyy as the *official* version. That should give us enough room to do version comparison by recognizing the first segment as a year instead of a major version. (18.x also looks like a semver, which should be avoided) Another con is that it is quite hard to recognize the LTS. I would prefer to have X. to be the LTS. That would imply that you could continue with the MM in the scheme. Assuming the version will start with the year, it might look like this: (D) GA (March 2018) 2018.03 First update (April) 2018.03.1 Second update (July) 2018.03.4 GA (September 2018) 2018.09 First update (October) 2018.09.1 Second update (January) 2018.09.4 GA (March 2019) 2018.15 (LTS) First update (April) 2018.15.1 Second update (July) 2018.15.4 GA (September 2019) 2019.09 First update (October) 2019.09.1 Second update (January) 2019.09.4 I'm also worried about the version as passed to different jdktools, like source/target/release. Its value is easy to link with a certain Java version and there are no gaps. Switching the a year-based version scheme would either lead to gaps or to an alias that doesn't match the Java Version (e.g. 10 for 18.3) thanks, Robert From forax at univ-mlv.fr Sun Oct 22 18:24:37 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 22 Oct 2017 20:24:37 +0200 (CEST) Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: <1660386078.2474110.1508696677182.JavaMail.zimbra@u-pem.fr> Yes, i was thinking exactly the same things reading the comments on this thread, 2018.3 is the distribution version, a position on the time axis while 10.0.0 is the internal version, a position on the compatibility axis (following JEP 223). Not only SQL Server works that way, Windows also works that way and if we take a look to the past, jJva release where defined by there nickname (kestrel, tiger, mustang) [1] and not only by the 3-dots version not so long ago. regards, R?mi [1] http://www.oracle.com/technetwork/java/javase/codenames-136090.html ----- Mail original ----- > De: "Dave Franken" > ?: "Robert Scholte" > Cc: jdk-dev at openjdk.java.net > Envoy?: Dimanche 22 Octobre 2017 19:15:08 > Objet: Re: Version-string schemes for the Java SE Platform and the JDK > How about using a separate version number for internal and public usage? > > Internally, we can keep things semantic based on a more logical numbering > starting with the current version, so just 9, 10 etc based on whatever is > in the release. > > Publically we can use whatever we want, such as yyyy.mm. I think it's > important to show the difference between LTS and non LTS, so I would just > use yyyy for the LTS versions and yyyy.update for intermediate non LTS > versions. > > SQL Server does this where SQL Server 2012 is 13.0 internally or something > like that. And then you get R2 for an updated version. > > Windows also always had a different internal and public version number. > > Kind regards, > > Dave Franken > > > Op 22 okt. 2017 15:50 schreef "Robert Scholte" : > > - Are there additional pros and cons to the alternatives listed above? > > The usage of yy cons is that in case we want another version scheme in the > future (e.g. back to SemVer-like scheme) we will be block once we reach > version 17. We should not assume that this will be the final switch of the > versioning scheme. JEP223 only being applied for Java 9 is a good example. > Assuming the year will be part of the scheme, I would advice to use yyyy as > the *official* version. That should give us enough room to do version > comparison by recognizing the first segment as a year instead of a major > version. (18.x also looks like a semver, which should be avoided) > > Another con is that it is quite hard to recognize the LTS. I would prefer > to have X. to be the LTS. That would imply that you could continue > with the MM in the scheme. Assuming the version will start with the year, > it might look like this: > > (D) > GA (March 2018) 2018.03 > First update (April) 2018.03.1 > Second update (July) 2018.03.4 > GA (September 2018) 2018.09 > First update (October) 2018.09.1 > Second update (January) 2018.09.4 > GA (March 2019) 2018.15 (LTS) > First update (April) 2018.15.1 > Second update (July) 2018.15.4 > GA (September 2019) 2019.09 > First update (October) 2019.09.1 > Second update (January) 2019.09.4 > > I'm also worried about the version as passed to different jdktools, like > source/target/release. Its value is easy to link with a certain Java > version and there are no gaps. Switching the a year-based version scheme > would either lead to gaps or to an alias that doesn't match the Java > Version (e.g. 10 for 18.3) > > thanks, > Robert From roman at kennke.org Sun Oct 22 19:43:42 2017 From: roman at kennke.org (Roman Kennke) Date: Sun, 22 Oct 2017 21:43:42 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <1660386078.2474110.1508696677182.JavaMail.zimbra@u-pem.fr> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> <1660386078.2474110.1508696677182.JavaMail.zimbra@u-pem.fr> Message-ID: <1ea079ab-f86d-c276-f6af-307b595489de@kennke.org> > Yes, i was thinking exactly the same things reading the comments on this thread, > 2018.3 is the distribution version, a position on the time axis while 10.0.0 is the internal version, a position on the compatibility axis (following JEP 223). Oh no! Why? We've been there before. For a bunch of releases the new version scheme (e.g. 6) was used outside, for marketing purposes, and the internal version still used the old scheme (e.g. 1.6.0). Has it done anything good to anybody? It just makes things more complicated, especially when there is no easy mapping (there was one back then: you could go from Java $X to Java 1.$X.0 relatively easily). I've read through most arguments and explanations, and one thing I really still cannot point my finger at is the big 'why?' What pressing need do we have to change version numbers *once again*, now that we're finally at a point where everybody has internalized the current scheme? For the most part, Java history nowadays starts at Java6. (Yes I know there's the lone old 1.4 deployment here and there.) A change like this is causing friction and disruption all over the place (and not in a positive sense), and this seems only justified when we have really good reasons to do so. I still cannot see them. On the upside, does this mean that Java is so good that we don't have more important issues to argue about and spend our time and energy on? (I don't think so. I'd like to see similarily lively discussions about, the vulnerability group, how JPRT can be made accessible to the outside world, if/how to open source the TCK, just to name 3 examples that I consider relatively important). Cheers, Roman From marcus at lagergren.net Mon Oct 23 07:08:53 2017 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 23 Oct 2017 09:08:53 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: <391D6F8E-892A-4EEF-A670-A830072E3117@lagergren.net> OK. Just one thing really? It?s the only thing that matters for determinism. Reproducible builds. ?This change number corresponds to the exact state of the repo when this was built. It can be synced to and reproduced?. And a single version control change number for said reproducible build as part of version string. Like all other complex commercial software in the world. *ducking and taking cover* /M > On 19 Oct 2017, at 17:08, mark.reinhold at oracle.com wrote: > > (This is a long note on a complex topic that's inherently difficult to > discuss. If you wish to reply, please first read all the way through > to the end.) > > In my proposal to adopt a strict six-month release cadence I suggested > that, going forward, the version strings of feature releases be of the > form $YEAR.$MONTH [1][2]. Thus next year's March release would be 18.3, > the September release would be 18.9, and so on each year. > > Not everyone likes this proposal, which isn't surprising -- discussions > of version-string schemes, much like those of language syntax, often tend > to degenerate into bike-sheds [3][4]. That's due, in part, to the use of > version strings -- across the software industry and for several decades > now -- to encode multiple not-quite-orthogonal axes of information, which > can answer different but often related questions: > > - Compatibility -- "Will my code break if I upgrade to this release?" > > - Significance -- "How different is this release from what I have now?" > > - Security -- "Does this release contain new security fixes?" > > - Support -- "For how long will this release be supported?" > > - Identity -- "On exactly which build was this bug reported against?" > > - Time -- "When did this release ship? How far behind am I?" > > Convention dictates that the principal part of a version string, i.e., > the version number, be a sequence of numerals separated by period > characters. (Let's ignore, for now, optional information such as > pre-release status and build numbers.) Convention also dictates that > version numbers be pointwise totally ordered, that they increase > monotonically over time, and that the version number of a feature > release be a prefix of the version numbers of its update releases. > > Given these conventions and a strict, time-based release cadence, which > of the above axes are both important and appropriate to encode into > version numbers? Which are practical to encode into version numbers? > Which should have more weight, i.e., be encoded in the earlier numerals > of version numbers, and which should have less weight, i.e., be encoded > in the later numerals? > > Some considerations for each axis, in turn: > > - Compatibility is obviously important -- it's one of the core values > of the Java Platform, after all -- but it's problematic in at least > two respects and hence not a sound basis for version numbers. > > First: Compatibility is, itself, multi-dimensional and therefore > difficult to encode into a simple sequence of numerals. What counts > as an incompatible change? > > Some cases are obvious, e.g., a language change after which some old > source files no longer compile, a JVM change after which some old > class files are no longer valid, or an API change that removes an > existing module, package, type, or element thereof. > > Many cases are, however, less than obvious, e.g., a language change > after which some previously-rejected source files do compile, a bug > fix that changes the element order of an array returned by an API, > an enhancement that allows a command-line option to accept some > previously-rejected arguments, or an optimization that removes an > internal API. > > It might be practical to encode compatibility information into a two- > or three-numeral version number for something as simple as a single > library whose only interface with the outside world is its API [5]. > It's far from clear how to do that, though, in a way that's easy for > everyone to understand for something as complex as the Java Platform > itself, and implementations thereof. > > Second: The compatibility of a particular release with any of its > predecessors depends upon the set of features in that release. In a > time-based release model, however, the set of features is not known > until late in each release cycle, after the final feature is merged. > This complicates discussions of any specific release and the tracking > of changes in JIRA and related systems. If, e.g., we use the leading > numerals of version numbers to encode compatibility in the usual way, > with the first numeral increasing only when incompatible changes are > made, then would the March 2018 release be version 9.1, or 10? We > can't know until some time in December 2017, when the release closes > for stabilization. > > We could address this problem by establishing secondary, time-based > labels for releases, but that would be awkward and could lead to even > more confusion. > > - Significance is even harder to measure than compatibility, and like > compatibility it depends upon the set of features in a release and > hence can't be known until late in a release cycle. The best we can > do for significance is insist that, over time, differences in version > numbers roughly reflect differences in release content. An increment > of the first numeral of a version number should indicate a greater > amount of change than increments of later numerals. > > - Security is important, but the security level can't be encoded in > one of the earlier numerals of a version number since it evolves at > a rate that's unpredictable relative to all the other axes and would > therefore violate the monotonicity constraint. > > (JEP 223 [6] solved this problem by using the third numeral of a > version number to record the security level of a release within a > particular major-release family, resetting that number only at the > next major release. That scheme was, however, designed under the > assumption of multi-year major releases, each of which could have > several simultaneous update-release lines. If security fixes are > routinely delivered in one stream of update releases per feature > release, as envisioned in this new model [7], then there's less > reason to encode the security level in the version number.) > > - The support lifetime of a release is useful information, but it's not > appropriate to encode that into the version number of the Java SE > Platform or the JDK. The version number should be identical in all > implementations of a given release, but the support lifetime of a > release may vary from implementor to implementor. Oracle might > choose, e.g., to offer support to its customers for twenty years on > releases three years apart, but another implementor might offer > support for ten years on releases two years apart. > > - Identity is important, especially for use in bug reports, but it need > not be encoded in the version number itself. It's reasonable to ask > that bug reports include the full version string, so it suffices to > include a build identifier or other implementation information after > the version number itself (e.g., 9+181, the full version string of > JDK 9 GA). > > These considerations leave us with the final axis, time, as the leading > candidate for the primary basis of Java SE and JDK version numbers. > > This would be a departure from past releases, in which we've used version > numbers that roughly encode both compatibility and significance. It is, > however, a better fit for a strict, time-based release model since the > version number of any particular release is known well in advance. The > compatibility level of a release would still be indicated by the length > of its version number, since we'll continue our long-standing practice > of making obviously-incompatible changes only in feature releases. The > security level of an update release would, similarly, be reflected in its > version number as a whole, since a later release will always contain more > security fixes than its predecessor. > > The main remaining question, then, is that of how to encode time in > version numbers: As an absolute value, derived from the date of the > release, or as a relative value, measuring the amount of time since > the previous release of the same type? > > In the abstract, absolute times have three attractive properties: > > - Absolute times reflect release dates, so they make it clear to all > involved -- both developers of the JDK and users of the JDK -- that > these are time-based releases. There can be no question of delaying > a release in order to add "just one more feature" to it. > > - Absolute times make it easy to figure out how old a release is, so > that as a user you can understand how far behind you are. Relative > times require you to know what the time units are, and when these > time-based version numbers were adopted. > > - Absolute times are independent of the release cadence. If in a few > years we switch to an even faster cadence, say every three months, > then an absolute scheme would need no change but a relative scheme > would need to be revised with a new time unit and starting point. > > Now, at last, for some concrete alternatives: > > (A) Absolute: $YY$MM, padding the month number with a zero as needed, > and $YY$MM.$AGE for update releases, where $AGE is the number of > months since $YY$MM. > > (B) Absolute: $YY.$M as proposed, without padding the month number, > and $YY.$M.$AGE for update releases, where $AGE is as above. > > (C) Relative: $N, where $N is the number of half-years since JDK 9 GA > (September 2017) plus nine, and $N.$AGE for update releases, where > $AGE is as above. ($AGE is more useful than another incrementing > counter since it leaves room for emergency update releases without > having to renumber subsequent update releases that are already in > development.) > > Examples of these alternatives, for the next two feature releases and > their first two update releases: > > (A) (B) (C) > GA (March 2018) 1803 18.3 10 > First update (April) 1803.1 18.3.1 10.1 > Second update (July) 1803.4 18.3.4 10.4 > GA (September 2018) 1809 18.9 11 > First update (October) 1809.1 18.9.1 11.1 > Second update (January) 1809.4 18.9.4 11.4 > > Some pros (+) and cons (-) of each alternative (some of these points are > subjective, but so it goes with this topic): > > (A) $YY$MM, with $YY$MM.$AGE for updates > > (+) Has the three advantages of absolute times. > > (+) The `Runtime.Version` API introduced by JEP 223 can be adapted > fairly easily. Code that parses raw version strings would need > little or no change (as long as it already does so correctly!). > > (-) On the surface 1803 is an enormous leap from 9, is likely to > cause confusion, and has connotations of being very old [8]. > > (B) $YY.$M, with $YY.$M.$AGE for updates > > (+) Has the three advantages of absolute times. > > (+) Similar to some other significant platforms, e.g., Ubuntu Linux, > and less shocking in appearance than (A). > > (-) People unfamiliar with the scheme could conflate 18.3 and 18.9 as > being minor releases of JDK 18, which isn't the case. There is > some evidence of similar confusion around Ubuntu releases [9]. > > (-) The logical "major" version number is now a pair of numbers, year > and month. We could mitigate this in the `Runtime.Version` API > by encoding the year and month as $YY$MM in the existing major > number, and adding new methods that return the year and month. > Code that parses raw version strings will likely require change, > including code not just in the JDK itself but in existing tools > and CI systems [a]. > > (C) $N, with $N.$AGE for updates > > (+) The most straightforward and least-surprising option, and > familiar from other rapidly-evolving projects such as Firefox > and Chrome. > > (+) The `Runtime.Version` API can be adapted very easily, and code > that (correctly) parses raw version strings would need no change. > > (-) Lacks the three advantages of absolute times. > > (-) If we ever switch to an even faster cadence then we could > eventually have very large version numbers, as in (A). In the > limit we could wind up in a situation like that of CoreOS, whose > latest stable release is numbered 1520.6 [b]. > > These are three plausible alternatives; there are countless others, but > I suspect that many if not most are minor variants of these three. To > mention just two examples: > > - We could simplify our grandchildren's lives and represent the year > with four digits rather than two. That would, however, lead to even > longer version numbers. > > - We could zero-pad the month number in (B) so as to be exactly like > Ubuntu ($YY.$MM) which might make it a bit more obvious that JDK > 18.03 isn't an update release of JDK 18. This would only work, > though, so long as we never ship a feature release after September > in any particular year. (Ubuntu ships in April (04) and October > (10), so zero-padding really only helps them half the time.) > > * * * > > If you've read this far, my question to you now is not the question that > you might expect. Please don't say which version-number scheme you > prefer for Java SE and the JDK. Instead, please only communicate any > additional information that's relevant to the choice of such a scheme. > In particular: > > - Are there additional pros and cons to the alternatives listed above? > > - Are there additional alternatives worth considering, and if so what > are their pros and cons? > > - Are there specific experiences with other projects or products that > can inform this choice? > > In order to discourage this from devolving into another version-numbering > bike-shed discussion I'll give much greater weight to your first reply to > this message than to any other, so please think and write carefully > before you post. I'll also ignore replies-to-replies -- if you really > want to argue with someone else about one scheme vs. another then I won't > stop you, but I don't think that's a useful use of most readers' time. > Finally, I'll heavily discount replies that quote more text from this > message than add new text of their own, so please quote just the text > that's actually needed to provide context for your reply. > > In a week or so I'll summarize any new information received, and then > make a specific proposal. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://bikeshed.org/ > [4] https://wiki.haskell.org/Wadler's_Law > [5] http://semver.org > [6] http://openjdk.java.net/jeps/223 > [7] https://mreinhold.org/blog/forward-faster#Proposal > [8] https://en.wikipedia.org/wiki/1803 > [9] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004429.html > [a] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004352.html > [b] https://coreos.com/releases From ropalka at redhat.com Mon Oct 23 08:11:59 2017 From: ropalka at redhat.com (Richard Opalka) Date: Mon, 23 Oct 2017 10:11:59 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <93a23e27-5b03-0437-557e-22b66c19cab0@redhat.com> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> <93a23e27-5b03-0437-557e-22b66c19cab0@redhat.com> Message-ID: Hi Mark, On Fri, Oct 20, 2017 at 12:34 PM, Aleksey Shipilev wrote: > On 10/19/2017 05:08 PM, mark.reinhold at oracle.com wrote: > > Not everyone likes this proposal, which isn't surprising -- discussions > > of version-string schemes, much like those of language syntax, often tend > > to degenerate into bike-sheds [3][4]. > > To be honest, changing the version scheme *again* looks like bike-shedding > to me. We don't have to > reinvent the version scheme that is already widely understood. Especially > if the discussion about > the version schemes does not indicate there exists the perfect one. > I would say to majority of Java users JEP 223 makes perfect sense. We are happy such JEP exists and it is officially effective since Java 9. Please RECONSIDER if another versioning change is really necessary? There are other more important things you and your team should work on. Richard From vladimir.kozlov at oracle.com Mon Oct 23 17:23:34 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 23 Oct 2017 10:23:34 -0700 Subject: CFV: New JDK Reviewer: Dean Long Message-ID: I hereby nominate Dean Long (dlong) to JDK Reviewer. This is long overdue. Dean Long currently is member of HotSpot JIT compiler group. Before that he worked on embedded JVM - he did a lot contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 ports which were pushed into Open JDK year ago. He also contributed 17 changes into AOT project during its development. Unfortunately both projects, ARM and AOT, have only one combined changeset when they were pushed into Open JDK. In addition to that Dean contributed 33 changes directly to Open JDK Project [3]. Votes are due by 6 November 2017, 10:00 am PT. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Thanks, Vladimir Kozlov [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) From vladimir.x.ivanov at oracle.com Mon Oct 23 17:25:34 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 23 Oct 2017 20:25:34 +0300 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 10/23/17 8:23 PM, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. From igor.veresov at oracle.com Mon Oct 23 17:25:45 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 23 Oct 2017 10:25:45 -0700 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <3E038113-801D-4CBA-99FC-E8EF279BE6FE@oracle.com> Vote: yes igor > On Oct 23, 2017, at 10:23 AM, Vladimir Kozlov wrote: > > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT compiler group. Before that he worked on embedded JVM - he did a lot contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 ports which were pushed into Open JDK year ago. He also contributed 17 changes into AOT project during its development. Unfortunately both projects, ARM and AOT, have only one combined changeset when they were pushed into Open JDK. In addition to that Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) From vladimir.kozlov at oracle.com Mon Oct 23 17:25:58 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 23 Oct 2017 10:25:58 -0700 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <1f599346-e0ef-5ea7-ccca-b9acfb910d3e@oracle.com> Vote: yes On 10/23/17 10:23 AM, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 > ports which were pushed into Open JDK year ago. He also contributed 17 > changes into AOT project during its development. Unfortunately both > projects, ARM and AOT, have only one combined changeset when they were > pushed into Open JDK. In addition to that Dean contributed 33 changes > directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) > From harold.seigel at oracle.com Mon Oct 23 17:26:36 2017 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 23 Oct 2017 13:26:36 -0400 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <896f8f57-7d91-f9b7-b3f0-5f0c384f1d9a@oracle.com> Vote: yes Thanks, Harold On 10/23/2017 1:23 PM, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and > ARM32 ports which were pushed into Open JDK year ago. He also > contributed 17 changes into AOT project during its development. > Unfortunately both projects, ARM and AOT, have only one combined > changeset when they were pushed into Open JDK. In addition to that > Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) > From stefan.karlsson at oracle.com Mon Oct 23 17:28:03 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 23 Oct 2017 19:28:03 +0200 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: Vote: yes StefanK On 2017-10-23 19:23, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and > ARM32 ports which were pushed into Open JDK year ago. He also > contributed 17 changes into AOT project during its development. > Unfortunately both projects, ARM and AOT, have only one combined > changeset when they were pushed into Open JDK. In addition to that > Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) > From jiangli.zhou at oracle.com Mon Oct 23 17:44:27 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 23 Oct 2017 10:44:27 -0700 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <535E2C05-936F-4B77-A317-FC19D805F0E4@oracle.com> Vote: yes Thanks, Jiangli > On Oct 23, 2017, at 10:23 AM, Vladimir Kozlov wrote: > > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT compiler group. Before that he worked on embedded JVM - he did a lot contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 ports which were pushed into Open JDK year ago. He also contributed 17 changes into AOT project during its development. Unfortunately both projects, ARM and AOT, have only one combined changeset when they were pushed into Open JDK. In addition to that Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) From goetz.lindenmaier at sap.com Mon Oct 23 18:20:00 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Oct 2017 18:20:00 +0000 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: , Message-ID: <2E945A0A-54BA-46F1-9F8A-86A830E32365@sap.com> vote: yes Best regards G?tz > Am 23.10.2017 um 19:25 schrieb Vladimir Ivanov : > > Vote: yes > > Best regards, > Vladimir Ivanov > >> On 10/23/17 8:23 PM, Vladimir Kozlov wrote: >> I hereby nominate Dean Long (dlong) to JDK Reviewer. From martin.doerr at sap.com Mon Oct 23 18:26:42 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 Oct 2017 18:26:42 +0000 Subject: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: Vote: yes Martin -----Original Message----- From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Montag, 23. Oktober 2017 19:24 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Reviewer: Dean Long I hereby nominate Dean Long (dlong) to JDK Reviewer. This is long overdue. Dean Long currently is member of HotSpot JIT compiler group. Before that he worked on embedded JVM - he did a lot contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 ports which were pushed into Open JDK year ago. He also contributed 17 changes into AOT project during its development. Unfortunately both projects, ARM and AOT, have only one combined changeset when they were pushed into Open JDK. In addition to that Dean contributed 33 changes directly to Open JDK Project [3]. Votes are due by 6 November 2017, 10:00 am PT. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Thanks, Vladimir Kozlov [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) From coleen.phillimore at oracle.com Mon Oct 23 18:30:09 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 23 Oct 2017 14:30:09 -0400 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <49460f8a-3e96-dc9b-f7e9-6b4c813fef9b@oracle.com> Vote: yes On 10/23/17 1:23 PM, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and > ARM32 ports which were pushed into Open JDK year ago. He also > contributed 17 changes into AOT project during its development. > Unfortunately both projects, ARM and AOT, have only one combined > changeset when they were pushed into Open JDK. In addition to that > Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) > From igor.ignatyev at oracle.com Mon Oct 23 18:43:26 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 23 Oct 2017 11:43:26 -0700 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <6167791B-C0D6-4C71-956A-B5ACC07AA281@oracle.com> Vote: yes -- Igor > On Oct 23, 2017, at 10:23 AM, Vladimir Kozlov wrote: > > I hereby nominate Dean Long (dlong) to JDK Reviewer. From zgu at redhat.com Mon Oct 23 18:47:46 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 23 Oct 2017 14:47:46 -0400 Subject: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <6b89f53d-e7ec-ce85-6a41-d44d5cce8a32@redhat.com> Vote: yes -Zhengyu > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Montag, 23. Oktober 2017 19:24 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Dean Long > > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 > ports which were pushed into Open JDK year ago. He also contributed 17 > changes into AOT project during its development. Unfortunately both > projects, ARM and AOT, have only one combined changeset when they were > pushed into Open JDK. In addition to that Dean contributed 33 changes > directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) > From Sergey.Bylokhov at oracle.com Mon Oct 23 18:49:05 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Oct 2017 11:49:05 -0700 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: Vote: yes On 23/10/2017 10:23, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 > ports which were pushed into Open JDK year ago. He also contributed 17 > changes into AOT project during its development. Unfortunately both > projects, ARM and AOT, have only one combined changeset when they were > pushed into Open JDK. In addition to that Dean contributed 33 changes > directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) > -- Best regards, Sergey. From christoph.langer at sap.com Mon Oct 23 19:17:32 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Oct 2017 19:17:32 +0000 Subject: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <629b8e7eb98d45a1bece2443f59a1d60@sap.com> Vote:Yes Best regards Christoph > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of > Vladimir Kozlov > Sent: Montag, 23. Oktober 2017 19:24 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Dean Long > > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 > ports which were pushed into Open JDK year ago. He also contributed 17 > changes into AOT project during its development. Unfortunately both > projects, ARM and AOT, have only one combined changeset when they were > pushed into Open JDK. In addition to that Dean contributed 33 changes > directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22 > dean.long at oracle.com%22)+or+author(dlong)) From jesper.wilhelmsson at oracle.com Mon Oct 23 19:35:37 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 23 Oct 2017 21:35:37 +0200 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <1195D21A-5A5F-41D6-8CC1-B57D76E55723@oracle.com> Vote: yes /Jesper > On 23 Oct 2017, at 19:23, Vladimir Kozlov wrote: > > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT compiler group. Before that he worked on embedded JVM - he did a lot contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 ports which were pushed into Open JDK year ago. He also contributed 17 changes into AOT project during its development. Unfortunately both projects, ARM and AOT, have only one combined changeset when they were pushed into Open JDK. In addition to that Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) From serguei.spitsyn at oracle.com Mon Oct 23 22:42:10 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 23 Oct 2017 15:42:10 -0700 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <86adebc1-b713-993f-5413-23c971c55560@oracle.com> Vote: yes From tobias.hartmann at oracle.com Tue Oct 24 05:13:00 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 24 Oct 2017 07:13:00 +0200 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <69ee9f91-6f7b-a868-6aef-994a63d2300b@oracle.com> Vote: yes On 23.10.2017 19:23, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT compiler group. Before that he worked on embedded JVM > - he did a lot contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 ports which were pushed into Open > JDK year ago. He also contributed 17 changes into AOT project during its development. Unfortunately both projects, ARM > and AOT, have only one combined changeset when they were pushed into Open JDK. In addition to that Dean contributed 33 > changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to > this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) From volker.simonis at gmail.com Tue Oct 24 07:32:49 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 24 Oct 2017 09:32:49 +0200 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: Vote: yes On Mon, Oct 23, 2017 at 7:23 PM, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT compiler > group. Before that he worked on embedded JVM - he did a lot contributions > (the exact count is lost) into Oracle's AARCH64 and ARM32 ports which were > pushed into Open JDK year ago. He also contributed 17 changes into AOT > project during its development. Unfortunately both projects, ARM and AOT, > have only one combined changeset when they were pushed into Open JDK. In > addition to that Dean contributed 33 changes directly to Open JDK Project > [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) From rwestrel at redhat.com Tue Oct 24 07:46:31 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 24 Oct 2017 09:46:31 +0200 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: Vote: yes Roland. From magnus.ihse.bursie at oracle.com Tue Oct 24 08:04:02 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Oct 2017 10:04:02 +0200 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: Vote: yes /Magnus On 2017-10-23 19:23, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and > ARM32 ports which were pushed into Open JDK year ago. He also > contributed 17 changes into AOT project during its development. > Unfortunately both projects, ARM and AOT, have only one combined > changeset when they were pushed into Open JDK. In addition to that > Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) > From adinn at redhat.com Tue Oct 24 13:31:23 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 24 Oct 2017 14:31:23 +0100 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <5a839288-7ee7-c7e7-f2a1-1383ab15b654@redhat.com> Vote: yes On 23/10/17 18:23, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 > ports which were pushed into Open JDK year ago. He also contributed 17 > changes into AOT project during its development. Unfortunately both > projects, ARM and AOT, have only one combined changeset when they were > pushed into Open JDK. In addition to that Dean contributed 33 changes > directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From mandy.chung at oracle.com Tue Oct 24 15:36:47 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 24 Oct 2017 08:36:47 -0700 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <42f591f3-77c4-abf1-415c-a4e5239fe91e@oracle.com> Vote: yes Mandy From kim.barrett at oracle.com Wed Oct 25 04:24:58 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 25 Oct 2017 00:24:58 -0400 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: vote: yes > On Oct 23, 2017, at 1:23 PM, Vladimir Kozlov wrote: > > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT compiler group. Before that he worked on embedded JVM - he did a lot contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 ports which were pushed into Open JDK year ago. He also contributed 17 changes into AOT project during its development. Unfortunately both projects, ARM and AOT, have only one combined changeset when they were pushed into Open JDK. In addition to that Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) From magnus.ihse.bursie at oracle.com Wed Oct 25 10:17:00 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Oct 2017 12:17:00 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: <9253e722-e1b8-6221-1421-6e5db635165a@oracle.com> Mark, I have only seen universal acclaim on your decision to move to a six-month release model for OpenJDK. On the contrast, the suggested version change has met a lot of resistance, and disappearingly little praise. Yet, there seems to be little reason to make these two into a tightly coupled "take it or leave it" package. What could be a rallying cause, that would unify the community to work together with shifting up the development speed of Java, will instead be sawing the seeds of discord. And all for no good reason. As you well know, a new version scheme was created in JEP 223 for JDK 9 [1]. This was the result of a thourough analysis, and was grounded in discussions with multiple parties on what constitutes a good version number. Let me quote the goals from that JEP: > > * > > Be easily understandable by humans, and easily parsable by programs. > > * > > Align with current industry practices, in particular Semantic > Versioning . > > * > > Be adoptable by existing packaging systems and platform-deployment > mechanisms including RPM > , dpkg > , IPS > , and the > Java Network Launching Protocol (JNLP) > . > > * > > Eliminate the current practice of encoding two types of > information in one element of the version string, /i.e./, the > minor release number and the security level, which is difficult to > decipher and results in skipping many version numbers. > > * > > Provide a simple API for version-string parsing, validation, and > comparison. > All in all, these are reasonable goals for a versioning scheme, and I believe JEP 223 managed to meet these goals. In contrast, the year-based version schemes you propose fails to meet at least the two top-most goals. But even if it were to meet all goals, that would still not provide a good reason to change. Just as for all other technical changes in Java, there need to be some great enough *additional* merit to provide a reason to switch from the existing solution to another, new and unproven. I believe that at times it's good to take a step back, and look at the question of relevance [2]. You are providing a lot of arguments for a specific type of version format, but I have a hard time finding good reasons as to *why* the change of version format is necessary or even relevant, given a change in release cadence. In the rest of this mail, I'll try to extract reasons for deviating from status quo (JEP 223), in contrast to reasons for arguing for one type or other of new version schemes, and add some comments. On 2017-10-19 17:08, mark.reinhold at oracle.com wrote: > First: Compatibility is, itself, multi-dimensional and therefore > difficult to encode into a simple sequence of numerals. What counts > as an incompatible change? Semantic Versioning (semver) uses this rule: "increment the MAJOR version when you make incompatible API changes". [3] As you say, there are gray areas with the concept of "incompatible API changes" in the context of Java and the JDK, but that does not mean that this is a bad rule, only that it needs to be applied judiciously. Once again, let's look at what's currently governing Java version numbers. JEP 223 provides this definition: "The major version number, incremented for a major release that contains significant new features" [4]. In a break with semver, there is actually no requirements for breaking compatibility to bump the major version number, just that "significant new features" are added. This is a requirement that I believe will still be just as applicable for releases on a six month cadence. (If we're not able to add significant new features between releases, we have a much more serious problems than the version string!) > Second: The compatibility of a particular release with any of its > predecessors depends upon the set of features in that release. In a > time-based release model, however, the set of features is not known > until late in each release cycle, after the final feature is merged. > This complicates discussions of any specific release and the tracking > of changes in JIRA and related systems. If, e.g., we use the leading > numerals of version numbers to encode compatibility in the usual way, > with the first numeral increasing only when incompatible changes are > made, then would the March 2018 release be version 9.1, or 10? We > can't know until some time in December 2017, when the release closes > for stabilization. > > We could address this problem by establishing secondary, time-based > labels for releases, but that would be awkward and could lead to even > more confusion. The question you're discussing here is "what is convenient for the developers and release managers of OpenJDK", not "what is convenient for the users of OpenJDK". The number of the former outweight the latter in orders of magnitute, and so it's the only impact that's relevant in this discussion. > This would be a departure from past releases, in which we've used version > numbers that roughly encode both compatibility and significance. It is, > however, a better fit for a strict, time-based release model since the > version number of any particular release is known well in advance. Here's one of the few actual arguments for the reason to actually change the version string that I've been able to find. I will not challenge your conclusion (that a time-based versioning scheme will be a better fit for a time-based release model), but I do challenge the relevance of this argument. Why is it important to know the version number of a particular release in advance? To whom is it important? Release managers, or the users of Java?And even if it is important (which I seriously doubt), is it important enough to upend the current scheme? /Magnus [1] http://openjdk.java.net/jeps/223 [2] https://en.wikipedia.org/wiki/Ignoratio_elenchi [3] http://semver.org/ [4] http://openjdk.java.net/jeps/223#Version-numbers From scolebourne at joda.org Wed Oct 25 11:45:24 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 25 Oct 2017 12:45:24 +0100 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: On 19 October 2017 at 16:08, wrote: > - Compatibility -- "Will my code break if I upgrade to this release?" > - Significance -- "How different is this release from what I have now?" > - Security -- "Does this release contain new security fixes?" > - Support -- "For how long will this release be supported?" > - Identity -- "On exactly which build was this bug reported against?" > - Time -- "When did this release ship? How far behind am I?" Lets rule out axes that are not important first. "Significance" is the same as compatibility in most cases. "Security" is orthogonal. "Identity" should be dealt with by any sensible version scheme. "Time" is of no importance to any library/platform I've ever dealt with - you simply look it up if you need to care. Compatibility must be the key driver for versions. The broad rules of semver (semantic versioning) are widely adopted and understood within the software industry and any departure from it should be treated with great scepticism. Note that when I mention semver I consider it to be a general framework rather than a strict set of rules to follow - not everyone will make that distinction. As such, there will be general agreement around a number following the pattern x.y where the first number is the major version and represents the fundamental compatibility level of the software. The proposal 18.3 / 18.9 / 19.3 etc. is extremely objectionable because it gives the appearance of being a semver when it isn't. The issue is that a major change may occur in 18.9, which is 100% wrong in semver-style versioning. It gives the appearance of having made a major breaking change in a minor release - a massive no-no. As such, all version schemes using two separate digits where a major change happens with only the second digit changing MUST BE REJECTED. If a release can contain a major change then the first version number must change (unless the beta approach is used, see below). A "major change" must include at least language enhancements, method/class/module deletion and class file version change. As I understand the next few releases, each release will have at least one of these, and as such each one triggers a major release which requires the first "major" digit of the version number to change. A "minor change" would include adding a new method to an existing API, adding a new class/type, adding a new module. All of these would be fine to be accepted in the second "minor" digit of the version number with the "major" digit staying the same. > ...the set of features is not known > until late in each release cycle, after the final feature is merged. > ... then would the March 2018 release be version 9.1, or 10? We > can't know until some time in December 2017, when the release closes > for stabilization. Personally I don't think this is a major problem. In most systems I've worked on you allocate the number as being minor until someone commits a major change and then bump it to major. ie. March 2018 would be named 9.1 until a major change is committed when it would then be changed to 10. However, given how rare a minor-only release is likely to be, I don't think this is worth pursuing. > - The support lifetime of a release is useful information, but it's not > appropriate to encode that into the version number of the Java SE > Platform or the JDK. The version number should be identical in all > implementations of a given release, but the support lifetime of a > release may vary from implementor to implementor. The "Support" axis is the wildcard in the whole discussion. While it is true that in theory an implementor might provide LTS for release other than those that Oracle provides LTS for, there is a huge open question of whether they will, or whether it would be appropriate for them to do so. This is a huge missing piece of the puzzle on versioning, and can radically change the result of the discussion: For example, if Oracle and the community were to agree that LTS releases are the new "real" releases, then the most appropriate version scheme would be one that reflected that: 9 (Set 2017) - now designated an LTS release 10-BETA-1 (Mar 2018) 10 (Sept 2018) - an LTS release (example) 11-BETA-1 (Mar 2019) 11-BETA-2 (Sep 2019) 11-BETA-3 (Mar 2020) 11 (Sep 2020) - an LTS release (example) etc This is really clear as to what the releases are - beta releases in preparation for an LTS. It is also much clearer that you shouldn't use them once the next beta is out. Obviously some organizations reject using beta code in production, but they would probably be the same organizations that will only use an LTS anyway. To adopt this requires broad agreement from all OpenJDK participants that LTS releases are the only full releases (and implied in that is probably that Java SE 9 is a "real" release simply because of its name). > These considerations leave us with the final axis, time, as the leading > candidate for the primary basis of Java SE and JDK version numbers. As indicated above, I (and many others) reject this conclusion, and thus most of the rest of the arguments in the email are null and void. > - Are there additional pros and cons to the alternatives listed above? (B) fails the essential test that a major change MUST NOT occur in the second digit. As such it is immediately rejected. (A) and (C) do meet the test, although the reason suggested to use the age in months as the second digit is both weak and unnecessary. A third digit can represent emergency releases, or the update releases could go in units of 20 as now. (A) is weird because the number is so large. Developers talk about the Java version they use all the time, and this would make those discussions painful. And since the date of a release is in general completely unimportant, it should be rejected anyway. The description of (C) is weird because of the nonsensical attempt to link the first number in the scheme to time. If it is just a number then the potential problem of 3 monthly releases goes away. > - Are there additional alternatives worth considering, and if so what > are their pros and cons? I've outlined the BETA scheme above. To me it most clearly represents what the wider community would expect, as I think if you asked them, only LTS releases with support would count as "real" releases worthy of changing the first digit, and all other "releases" are simply betas working towards the LTS. Note that this implies that no piece of functionality can be deprecated in BETA1 and removed in BETA2, which would be a sensible approach anyway. The main con of the BETA scheme is that it encodes a specific LTS model into the version scheme. And I suspect there might be some pushback on the principle of downgrading 6 monthly release relative to the LTS ones. In my view this is actually just a statement of fact - as without support you are forced to upgrade making them clearly a lower grade of release. Now, if RedHat or someone else were to publicly say that they will support every 6 monthly release for a 5 year period, then the BETA scheme doesn't work. But IMO, the community would be better served by a widely agreed LTS release every 2 to 3 years, with BETA releases in between for advanced users. If the BETA scheme is rejected, the default should be to continue using the existing scheme - a simple incrementing number - 10, 11, 12, etc. This fits with JEP 223, causes no particular pain or issues with the wider community. The pros of this scheme are that it is well known, well understood and already works. It has the con that it doesn't help Oracle ship software on time, but thats not something that the version scheme should care about (and might even be viewed as a positive on rare occasions). See also David Lloyd's pros/cons of the current incrementing number scheme. > - Are there specific experiences with other projects or products that > can inform this choice? Java is a software platform, not an OS. It is closer to Apache Tomcat or Spring Framework than Ubuntu. So numbering schemes used by open source projects and maven central (almost all based on semver) should be the guide here. Summary: As others have emphasised, JEP 223 has discussed and decided this issue. There would have to be a very good reason to change the approach. The only justification I can possibly see is that there are now two grades of release - intermediate (no support beyond 6 months, thus forced upgrade) and full (LTS). None of the proposals in the original email represent that key distinction - the BETA scheme above does of course. Unless there is wide agreement on the concept of beta releases leading to a full LTS release, the only rational choice it to retain the existing JEP 223 numbering scheme, thus March 2018 is v10 and September is v11. Stephen From aph at redhat.com Wed Oct 25 12:04:12 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Oct 2017 13:04:12 +0100 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: <058d735a-9d3a-1490-8d9c-56e2214587eb@redhat.com> On 25/10/17 12:45, Stephen Colebourne wrote: > I've outlined the BETA scheme above. To me it most clearly > represents what the wider community would expect, as I think if you > asked them, only LTS releases with support would count as "real" > releases worthy of changing the first digit, and all other > "releases" are simply betas working towards the LTS. Note that this > implies that no piece of functionality can be deprecated in BETA1 > and removed in BETA2, which would be a sensible approach anyway. > > The main con of the BETA scheme is that it encodes a specific LTS > model into the version scheme. And I suspect there might be some > pushback on the principle of downgrading 6 monthly release relative > to the LTS ones. In my view this is actually just a statement of > fact - as without support you are forced to upgrade making them > clearly a lower grade of release. > > Now, if RedHat It's "Red Hat". > or someone else were to publicly say that they will support every 6 > monthly release for a 5 year period, then the BETA scheme doesn't > work. But IMO, the community would be better served by a widely > agreed LTS release every 2 to 3 years, with BETA releases in between > for advanced users. That may well be how it turns out, but we should not attempt to enforce that in the numbering scheme. For example, some organizations might well choose to take a six-month update which doesn't break anything but has some performance improvements and merge that into their LTS release. Thinking of the six-month releases as Betas doesn't help. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Oct 25 12:22:39 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Oct 2017 13:22:39 +0100 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <058d735a-9d3a-1490-8d9c-56e2214587eb@redhat.com> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> <058d735a-9d3a-1490-8d9c-56e2214587eb@redhat.com> Message-ID: <36b2501c-6b40-57e3-3204-453a9f115f64@redhat.com> On 25/10/17 13:04, Andrew Haley wrote: > On 25/10/17 12:45, Stephen Colebourne wrote: > >> or someone else were to publicly say that they will support every 6 >> monthly release for a 5 year period, then the BETA scheme doesn't >> work. But IMO, the community would be better served by a widely >> agreed LTS release every 2 to 3 years, with BETA releases in between >> for advanced users. > > That may well be how it turns out, but we should not attempt to > enforce that in the numbering scheme. For example, some organizations > might well choose to take a six-month update which doesn't break > anything but has some performance improvements and merge that into > their LTS release. Thinking of the six-month releases as Betas > doesn't help. Up to now, somebody who decides to work on OpenJDK as an undergraduate project might complete their PhD before their OpenJDK work sees the light of day. That is an intolerable situation. If we treat the six-monthly updates as merely Betas then we're in just as bad a position as we were before. If only LTS releases count as true releases then we will not have advanced the situation by one iota. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dnebinger at icloud.com Wed Oct 25 15:36:58 2017 From: dnebinger at icloud.com (David Nebinger) Date: Wed, 25 Oct 2017 11:36:58 -0400 Subject: Version-string schemes for the Java SE Platform and the JDK Message-ID: <76E69981-98B7-4266-B30F-9BDD3701E397@icloud.com> While this kind of versioning makes sense internally for geeks to understand the date of the release and age of the release, this assumes the only folks using or needing Java will be geeks. For any non-geeks, this kind of $YY.$M.$AGE will make absolutely no sense. I can get behind the $YY portion of versioning. Users would see Java 12, for example, as something really old. Java 19, though, keeps it new, hip and fresh. After that, though, I would recommend using incremental version numbers. 18.0.0 and 18.1.0 for your two major releases, and increment the last number for new security releases. Yes, for support folks we have to continue to maintain tables of versions to release dates - but understanding version differences is a support/developer issue, we should not push this detail out to regular Java users. From neugens.limasoftware at gmail.com Wed Oct 25 20:28:46 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 25 Oct 2017 22:28:46 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: 2017-10-25 13:45 GMT+02:00 Stephen Colebourne : > For example, if Oracle and the community were to agree that LTS > releases are the new "real" releases, then the most appropriate > version scheme would be one that reflected that: I resisted the urge to reply on other posts as per Mark's original request, but I think it's very important that we keep in mind that the short lived released in between the LTS are not beta, they are full high quality, stable and production ready releases. While I also think that LTS will be the one most used in the industry, it's only because they live longer, they don't necessarily have a special merit over any other release. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From dwfranken at gmail.com Thu Oct 26 08:19:51 2017 From: dwfranken at gmail.com (Dave Franken) Date: Thu, 26 Oct 2017 10:19:51 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: <000b01d34e33$3294af60$97be0e20$@gmail.com> Now that I've read a lot of arguments in this discussion, I'm beginning to have some doubts about the whole "time based just include what's ready" release cycle, especially with regards to LTS versions and backwards compatibility. If we don't do any cherry picking about the types of features that end up in a release, we could have the version number bumping all over the place. We could go from 9 to 10 to 11 in 2018 alone (10 being the March version and 11 being the September LTS version). Backwards compatibility has always been Java's strong suit, but it came at a cost of slow language improvements. With the proposed release cycle and version numbers, I feel the pendulum swings too far to the other side. Can we have the best of both worlds? I think that there should be some more discussion about not just the version numbers, but the reason we have to argue about them in the first place, the underlying issue of time based releases. My proposal is that there should be some restraint in adding backwards incompatible features in non-LTS releases, for instance local type inference (JEP 286) and value types (project Valhalla). A non-LTS version may incorporate all finished features that don't result in bumping $MAJOR. This means that developers don't have to worry about using non-LTS versions, they also don't feel like Betas, just updates to the version you might already be using. They only have internal performance improvements, security fixes etc that don't break your code. Issues that break backwards compatibility should still be bundled in LTS versions, we should just strive to not have to wait many years for them. Applying Stephen Colebourne's example to my proposal would result in: 9 (Sept 2017) - now designated an LTS release(?) 9.1 (Mar 2018) 10 (Sept 2018) - an LTS release (example, including JEP 286) 10.1 (Mar 2019) 10.2 (Sep 2019) 10.3 (Mar 2020) 11 (Sep 2020) - an LTS release (example, including project Valhalla) We can still have more frequent releases while being careful about backwards compatibility. Kind regards, Dave Franken -----Original Message----- From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Mario Torre Sent: woensdag 25 oktober 2017 22:29 To: Stephen Colebourne Cc: jdk-dev at openjdk.java.net Subject: Re: Version-string schemes for the Java SE Platform and the JDK 2017-10-25 13:45 GMT+02:00 Stephen Colebourne : > For example, if Oracle and the community were to agree that LTS > releases are the new "real" releases, then the most appropriate > version scheme would be one that reflected that: I resisted the urge to reply on other posts as per Mark's original request, but I think it's very important that we keep in mind that the short lived released in between the LTS are not beta, they are full high quality, stable and production ready releases. While I also think that LTS will be the one most used in the industry, it's only because they live longer, they don't necessarily have a special merit over any other release. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From aph at redhat.com Thu Oct 26 09:02:03 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Oct 2017 10:02:03 +0100 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <000b01d34e33$3294af60$97be0e20$@gmail.com> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> <000b01d34e33$3294af60$97be0e20$@gmail.com> Message-ID: <52d847ef-81a8-3826-ae7a-1bb957eaf621@redhat.com> On 26/10/17 09:19, Dave Franken wrote: > My proposal is that there should be some restraint in adding backwards incompatible features in non-LTS releases, for instance local type inference (JEP 286) and value types (project Valhalla). That's a bad idea. It'd be extremely useful to bake anew language features for some time before committing them to a LTS release. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dwfranken at gmail.com Thu Oct 26 09:53:39 2017 From: dwfranken at gmail.com (Dave Franken) Date: Thu, 26 Oct 2017 11:53:39 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <52d847ef-81a8-3826-ae7a-1bb957eaf621@redhat.com> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> <000b01d34e33$3294af60$97be0e20$@gmail.com> <52d847ef-81a8-3826-ae7a-1bb957eaf621@redhat.com> Message-ID: <000d01d34e40$4d14d240$e73e76c0$@gmail.com> I assume we have the proper testing procedures in place to ensure the stability of any release, not just the LTS versions, but maybe more so for the LTS versions. This means that nothing gets released, LTS or non-LTS unless properly tested, right? We could still release RC versions prior to LTS if we desperately want this feedback. Dave Franken -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: donderdag 26 oktober 2017 11:02 To: Dave Franken ; 'Mario Torre' ; 'Stephen Colebourne' Cc: jdk-dev at openjdk.java.net Subject: Re: Version-string schemes for the Java SE Platform and the JDK On 26/10/17 09:19, Dave Franken wrote: > My proposal is that there should be some restraint in adding backwards incompatible features in non-LTS releases, for instance local type inference (JEP 286) and value types (project Valhalla). That's a bad idea. It'd be extremely useful to bake anew language features for some time before committing them to a LTS release. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Oct 26 09:58:56 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Oct 2017 10:58:56 +0100 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <000d01d34e40$4d14d240$e73e76c0$@gmail.com> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> <000b01d34e33$3294af60$97be0e20$@gmail.com> <52d847ef-81a8-3826-ae7a-1bb957eaf621@redhat.com> <000d01d34e40$4d14d240$e73e76c0$@gmail.com> Message-ID: <5062b9b5-20c2-6232-4e2e-7d151df09803@redhat.com> On 26/10/17 10:53, Dave Franken wrote: > I assume we have the proper testing procedures in place to ensure > the stability of any release, not just the LTS versions, but maybe > more so for the LTS versions. This means that nothing gets > released, LTS or non-LTS unless properly tested, right? Yes. But this isn't about testing. It's about gaining experience with new language features in the real world, and filling in gaps as needed. We have found out that convenient facilities were missing in new features. This is IMO the whole point of frequent releases. To encourage development of language features and get the benefit of the rapid deploy-use-modify virtuous circle. If we don't do this we may as well go back to the old model. > We could still release RC versions prior to LTS if we desperately > want this feedback. Sure, but it's not really the same thing. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From scolebourne at joda.org Thu Oct 26 10:05:06 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 26 Oct 2017 11:05:06 +0100 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: On Twitter, the @VincentPrivat suggested "M" for milestone as a better term for the intermediate releases than "BETA". I agree. This would give: 9 (Set 2017) - now designated an LTS release 10-M1 (Mar 2018) 10 (Sept 2018) - an LTS release (example) 11-M1 (Mar 2019) 11-M2 (Sep 2019) 11-M3 (Mar 2020) 11 (Sep 2020) - an LTS release (example) Lets call this the MILESTONE version scheme in discussions. Again I emphasise that if this is not acceptable, the only rational choice is simple incrementing numbers as today, although in my view they fail to capture the lack of support / forced migration of non LTS releases, ie. whether something is LTS or not should be the primary driver of the version scheme IMO. Stephen On 25 October 2017 at 12:45, Stephen Colebourne wrote: > The "Support" axis is the wildcard in the whole discussion. While it > is true that in theory an implementor might provide LTS for release > other than those that Oracle provides LTS for, there is a huge open > question of whether they will, or whether it would be appropriate for > them to do so. This is a huge missing piece of the puzzle on > versioning, and can radically change the result of the discussion: > > For example, if Oracle and the community were to agree that LTS > releases are the new "real" releases, then the most appropriate > version scheme would be one that reflected that: > > 9 (Set 2017) - now designated an LTS release > 10-BETA-1 (Mar 2018) > 10 (Sept 2018) - an LTS release (example) > 11-BETA-1 (Mar 2019) > 11-BETA-2 (Sep 2019) > 11-BETA-3 (Mar 2020) > 11 (Sep 2020) - an LTS release (example) > etc From cedric.champeau at gmail.com Thu Oct 26 10:21:49 2017 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Thu, 26 Oct 2017 12:21:49 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: I'm in line with what Stephen said here, apart from the BETA scheme which gives wrong impression of low quality. I cannot speak for Gradle as an organization, but I can say we *do* have experience on what version numbers mean. For a library or a platform like the JDK, semantic versioning makes a lot of sense. So I would very much prefer: - 10.0.0 // first 10 release - 10.1.0 // adds new APIs, backwards compatible, NO class version upgrade - 11.0.0 // adds new APIs, backwards compatible maybe, BUT increases class version number because of new feature X One rationale for this is that we already fight with tracking version numbers for Java, because we need to support _at runtime_ different versions (6 to 9, different vendors, ...) and we already see version strings like 9.0.1-ea. It does NOT prevent the JDK from being *branded* as 18.3.LTS. So, marketing wise, you would have: - 18.3.LTS -> 10.0.0 (internal version number, used by tools and referring to the actual platform version) - 18.9 -> 11.0.0 etc... We just need a consistent versioning scheme, that is widely adopted and that tools can reason about. Unfortunately the 18.3 format doesn't allow us to infer anything about backwards compatibility. 2017-10-26 12:05 GMT+02:00 Stephen Colebourne : > On Twitter, the @VincentPrivat suggested "M" for milestone as a better > term for the intermediate releases than "BETA". I agree. This would > give: > > 9 (Set 2017) - now designated an LTS release > 10-M1 (Mar 2018) > 10 (Sept 2018) - an LTS release (example) > 11-M1 (Mar 2019) > 11-M2 (Sep 2019) > 11-M3 (Mar 2020) > 11 (Sep 2020) - an LTS release (example) > > Lets call this the MILESTONE version scheme in discussions. > > Again I emphasise that if this is not acceptable, the only rational > choice is simple incrementing numbers as today, although in my view > they fail to capture the lack of support / forced migration of non LTS > releases, ie. whether something is LTS or not should be the primary > driver of the version scheme IMO. > > Stephen > > On 25 October 2017 at 12:45, Stephen Colebourne > wrote: > > The "Support" axis is the wildcard in the whole discussion. While it > > is true that in theory an implementor might provide LTS for release > > other than those that Oracle provides LTS for, there is a huge open > > question of whether they will, or whether it would be appropriate for > > them to do so. This is a huge missing piece of the puzzle on > > versioning, and can radically change the result of the discussion: > > > > For example, if Oracle and the community were to agree that LTS > > releases are the new "real" releases, then the most appropriate > > version scheme would be one that reflected that: > > > > 9 (Set 2017) - now designated an LTS release > > 10-BETA-1 (Mar 2018) > > 10 (Sept 2018) - an LTS release (example) > > 11-BETA-1 (Mar 2019) > > 11-BETA-2 (Sep 2019) > > 11-BETA-3 (Mar 2020) > > 11 (Sep 2020) - an LTS release (example) > > etc > From aph at redhat.com Thu Oct 26 10:28:34 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Oct 2017 11:28:34 +0100 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: <83178c2b-c902-65da-462c-379a0abc993b@redhat.com> On 26/10/17 11:05, Stephen Colebourne wrote: > On Twitter, the @VincentPrivat suggested "M" for milestone as a better > term for the intermediate releases than "BETA". I agree. This would > give: > > 9 (Set 2017) - now designated an LTS release > 10-M1 (Mar 2018) > 10 (Sept 2018) - an LTS release (example) > 11-M1 (Mar 2019) > 11-M2 (Sep 2019) > 11-M3 (Mar 2020) > 11 (Sep 2020) - an LTS release (example) > > Lets call this the MILESTONE version scheme in discussions. Let's not. Six-monthly releases are releases, not milestones. IMO: This whole discussion has been mistracked by the notion that we're going to continue with Java development as we have in the past, with true big feature releases every few years. That is wrong, and it has to end. Java is hurting because we are not getting the benefit of the release early, release often loop. Done right, this allows development to proceed more quickly and gets faster feedback from users. The world of language development outside Java is moving much faster, and we run the risk of becoming a dinosaur if we're too slow. I know this has risks. It pushes the edges of our comfort zones. But it's also exciting and could be terrific if done well. > Again I emphasise that if this is not acceptable, the only rational > choice is simple incrementing numbers as today, This is rather strong. Mark's suggestions are not irrational; on the contrary, the choices are supported with reasoned argument. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From doko at ubuntu.com Thu Oct 26 22:56:00 2017 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 27 Oct 2017 00:56:00 +0200 Subject: version numbers for distribution builds? Message-ID: <85a1bac3-a933-c48b-080a-0525657cf080@ubuntu.com> Hi, I recently learned that I should configure an openjdk build with an empty -with-version-pre string, and with any package information stuffed into the --with-version-opt argument. --with-version-pre='' --with-version-opt='Debian-9.0.1+11-1' 9.0.1+11 is what I call the upstream version, directly derived from the tag in the mercurial repository. The part after the dash is the packaging release and gets incremented when more than upload to the distribution is based on the same upstream version. However using that I get configure: WARNING: --with-version-opt value has been sanitized from 'Debian-9.0.1+11-1' to 'Debian-9.0.111-1' which makes the version string somehow cryptic. Why is there a reason that the version string is mangled? Is there a recommendation how to form the version for a source release? Thanks, Matthias From doko at ubuntu.com Thu Oct 26 23:13:32 2017 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 27 Oct 2017 01:13:32 +0200 Subject: version numbers for distribution builds? In-Reply-To: <85a1bac3-a933-c48b-080a-0525657cf080@ubuntu.com> References: <85a1bac3-a933-c48b-080a-0525657cf080@ubuntu.com> Message-ID: <544dc6f7-d9fa-6a50-258a-d596b4aa11c7@ubuntu.com> On 27.10.2017 00:56, Matthias Klose wrote: > Hi, > > I recently learned that I should configure an openjdk build with an empty > -with-version-pre string, and with any package information stuffed into the > --with-version-opt argument. > > --with-version-pre='' --with-version-opt='Debian-9.0.1+11-1' > > 9.0.1+11 is what I call the upstream version, directly derived from the tag in > the mercurial repository. The part after the dash is the packaging release and > gets incremented when more than upload to the distribution is based on the same > upstream version. > > However using that I get > > configure: WARNING: --with-version-opt value has been sanitized from > 'Debian-9.0.1+11-1' to 'Debian-9.0.111-1' > > which makes the version string somehow cryptic. Why is there a reason that the > version string is mangled? Is there a recommendation how to form the version > for a source release? $ java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+0-Debian-9.0.111-1) OpenJDK 64-Bit Server VM (build 9.0.1+0-Debian-9.0.111-1, mixed mode) Omar suggested on irc to use --with-version-pre='' --with-version-build=11 --with-version-opt='Debian.1 however that will lead to 9.0.1+11-Debian.1, which doesn't match the package version either. It looks like this whole versioning schema is only fit for upstream builds, and doesn't address any versioning in the downstream builds. Maybe I'm missing something, but how can I include the string Debian-9.0.1+11-1 into that build information? Matthias From mikael.vidstedt at oracle.com Fri Oct 27 02:55:36 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 26 Oct 2017 19:55:36 -0700 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <83178c2b-c902-65da-462c-379a0abc993b@redhat.com> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> <83178c2b-c902-65da-462c-379a0abc993b@redhat.com> Message-ID: > On Oct 26, 2017, at 3:28 AM, Andrew Haley wrote: > > On 26/10/17 11:05, Stephen Colebourne wrote: >> On Twitter, the @VincentPrivat suggested "M" for milestone as a better >> term for the intermediate releases than "BETA". I agree. This would >> give: >> >> 9 (Set 2017) - now designated an LTS release >> 10-M1 (Mar 2018) >> 10 (Sept 2018) - an LTS release (example) >> 11-M1 (Mar 2019) >> 11-M2 (Sep 2019) >> 11-M3 (Mar 2020) >> 11 (Sep 2020) - an LTS release (example) >> >> Lets call this the MILESTONE version scheme in discussions. > > Let's not. Six-monthly releases are releases, not milestones. > > IMO: > > This whole discussion has been mistracked by the notion that we're > going to continue with Java development as we have in the past, with > true big feature releases every few years. That is wrong, and it has > to end. Java is hurting because we are not getting the benefit of the > release early, release often loop. Done right, this allows > development to proceed more quickly and gets faster feedback from > users. The world of language development outside Java is moving much > faster, and we run the risk of becoming a dinosaur if we're too slow. Well said, thanks for summing up my thoughts for me :) > I know this has risks. It pushes the edges of our comfort zones. But > it's also exciting and could be terrific if done well. The new release model comes with a whole bunch of new challenges and risks for sure, but it?s not like the current model is problem free (understatement of the day?). I agree that this is a very exciting opportunity and I?m looking forward to working through issues as they arise. Cheers, Mikael From dwfranken at gmail.com Fri Oct 27 07:37:40 2017 From: dwfranken at gmail.com (Dave Franken) Date: Fri, 27 Oct 2017 09:37:40 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> <83178c2b-c902-65da-462c-379a0abc993b@redhat.com> Message-ID: <000401d34ef6$7879dcd0$696d9670$@gmail.com> It seems paradoxical to want to have both a rapidly evolving language and LTS-versions. Personally, I would be okay with having "just releases" containing everything that is releasable, whether it has incompatible features or not, as long as the version number reflects it. So basically JEP 223. No betas, no milestones, just $MAJOR.$MINOR.$PATCH/$SECURITY. Every release is stable and has new (possibly breaking) features, improvements, bug fixes, etc, so you can decide to upgrade based purely on the version number alone, telling you the most important information. We then have to ask ourselves: how many versions are we going to support with security updates? Say we quickly (within 1 year) arrive at version 11 because version 10 (18.3) has local type inference and 11 (18.9) has value types and at that point we have to do a security update. Which versions are we going to update? If we keep updating too many old versions, the sense of urgency to move on is lessened. But if we decide to only support the latest two versions (10 and 11), there is no way to tell how long your version will be supported. If you are still stuck on 10, it could be 2 years until 12 comes out (ending support for 10), or it could be 6 months, it just depends on what kinds of features are ready at that time. I'm all for a rapidly evolving language, much of the enterprise is getting ready for it with the use of containerized environments where upgrading Java is just a matter of changing a number somewhere. I just want to make sure we have ironed out all of the wrinkles before committing ourselves fully. The version number debate brings to light very important questions that are not strictly related to the version number, but are worth discussing in their own right. Dave Franken -----Original Message----- From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Mikael Vidstedt Sent: vrijdag 27 oktober 2017 4:56 To: Andrew Haley Cc: jdk-dev at openjdk.java.net Subject: Re: Version-string schemes for the Java SE Platform and the JDK > On Oct 26, 2017, at 3:28 AM, Andrew Haley wrote: > > On 26/10/17 11:05, Stephen Colebourne wrote: >> On Twitter, the @VincentPrivat suggested "M" for milestone as a >> better term for the intermediate releases than "BETA". I agree. This >> would >> give: >> >> 9 (Set 2017) - now designated an LTS release >> 10-M1 (Mar 2018) >> 10 (Sept 2018) - an LTS release (example) >> 11-M1 (Mar 2019) >> 11-M2 (Sep 2019) >> 11-M3 (Mar 2020) >> 11 (Sep 2020) - an LTS release (example) >> >> Lets call this the MILESTONE version scheme in discussions. > > Let's not. Six-monthly releases are releases, not milestones. > > IMO: > > This whole discussion has been mistracked by the notion that we're > going to continue with Java development as we have in the past, with > true big feature releases every few years. That is wrong, and it has > to end. Java is hurting because we are not getting the benefit of the > release early, release often loop. Done right, this allows > development to proceed more quickly and gets faster feedback from > users. The world of language development outside Java is moving much > faster, and we run the risk of becoming a dinosaur if we're too slow. Well said, thanks for summing up my thoughts for me :) > I know this has risks. It pushes the edges of our comfort zones. But > it's also exciting and could be terrific if done well. The new release model comes with a whole bunch of new challenges and risks for sure, but it?s not like the current model is problem free (understatement of the day?). I agree that this is a very exciting opportunity and I?m looking forward to working through issues as they arise. Cheers, Mikael From david.holmes at oracle.com Fri Oct 27 10:21:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Oct 2017 20:21:23 +1000 Subject: version numbers for distribution builds? In-Reply-To: <544dc6f7-d9fa-6a50-258a-d596b4aa11c7@ubuntu.com> References: <85a1bac3-a933-c48b-080a-0525657cf080@ubuntu.com> <544dc6f7-d9fa-6a50-258a-d596b4aa11c7@ubuntu.com> Message-ID: Adding build-dev. David On 27/10/2017 9:13 AM, Matthias Klose wrote: > On 27.10.2017 00:56, Matthias Klose wrote: >> Hi, >> >> I recently learned that I should configure an openjdk build with an empty >> -with-version-pre string, and with any package information stuffed into the >> --with-version-opt argument. >> >> --with-version-pre='' --with-version-opt='Debian-9.0.1+11-1' >> >> 9.0.1+11 is what I call the upstream version, directly derived from the tag in >> the mercurial repository. The part after the dash is the packaging release and >> gets incremented when more than upload to the distribution is based on the same >> upstream version. >> >> However using that I get >> >> configure: WARNING: --with-version-opt value has been sanitized from >> 'Debian-9.0.1+11-1' to 'Debian-9.0.111-1' >> >> which makes the version string somehow cryptic. Why is there a reason that the >> version string is mangled? Is there a recommendation how to form the version >> for a source release? > > $ java -version > openjdk version "9.0.1" > OpenJDK Runtime Environment (build 9.0.1+0-Debian-9.0.111-1) > OpenJDK 64-Bit Server VM (build 9.0.1+0-Debian-9.0.111-1, mixed mode) > > Omar suggested on irc to use > > --with-version-pre='' --with-version-build=11 --with-version-opt='Debian.1 > > however that will lead to 9.0.1+11-Debian.1, which doesn't match the package > version either. It looks like this whole versioning schema is only fit for > upstream builds, and doesn't address any versioning in the downstream builds. > > Maybe I'm missing something, but how can I include the string Debian-9.0.1+11-1 > into that build information? > > Matthias > From magnus.ihse.bursie at oracle.com Fri Oct 27 10:46:51 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 27 Oct 2017 12:46:51 +0200 Subject: version numbers for distribution builds? In-Reply-To: References: <85a1bac3-a933-c48b-080a-0525657cf080@ubuntu.com> <544dc6f7-d9fa-6a50-258a-d596b4aa11c7@ubuntu.com> Message-ID: <1e1cb94c-f9c3-e655-6beb-159b8b315b1a@oracle.com> On 2017-10-27 12:21, David Holmes wrote: > Adding build-dev. > > David > > On 27/10/2017 9:13 AM, Matthias Klose wrote: >> On 27.10.2017 00:56, Matthias Klose wrote: >>> Hi, >>> >>> I recently learned that I should configure an openjdk build with an >>> empty >>> -with-version-pre string, and with any package information stuffed >>> into the >>> --with-version-opt argument. >>> >>> ?? --with-version-pre='' --with-version-opt='Debian-9.0.1+11-1' >>> >>> 9.0.1+11 is what I call the upstream version, directly derived from >>> the tag in >>> the mercurial repository.? The part after the dash is the packaging >>> release and >>> gets incremented when more than upload to the distribution is based >>> on the same >>> upstream version. >>> >>> However using that I get >>> >>> configure: WARNING: --with-version-opt value has been sanitized from >>> 'Debian-9.0.1+11-1' to 'Debian-9.0.111-1' >>> >>> which makes the version string somehow cryptic.? Why is there a >>> reason that the >>> version string is mangled?? Is there a recommendation how to form >>> the version >>> for a source release? >> >> $ java -version >> openjdk version "9.0.1" >> OpenJDK Runtime Environment (build 9.0.1+0-Debian-9.0.111-1) >> OpenJDK 64-Bit Server VM (build 9.0.1+0-Debian-9.0.111-1, mixed mode) >> >> Omar suggested on irc to use >> >> ?? --with-version-pre='' --with-version-build=11 >> --with-version-opt='Debian.1 >> >> however that will lead to 9.0.1+11-Debian.1, which doesn't match the >> package >> version either.? It looks like this whole versioning schema is only >> fit for >> upstream builds, and doesn't address any versioning in the downstream >> builds. >> >> Maybe I'm missing something, but how can I include the string >> Debian-9.0.1+11-1 >> into that build information? Unfortunately, you can't. JEP 223 specifices what a valid Java version string looks like: http://openjdk.java.net/jeps/223 I believe your intention is correct to add the distribution versioning to the "opt" part, but that is limited to containing ([-a-zA-Z0-9\.]+) according to JEP 223, so it cannot contain a "+". (This is due to the fact that "+" has a special meaning as the build prefix, and without this restriction, version strings could become ambigious to parse. If you want the full version number repeated in the opt string, I recommend replacing the "+" with a "-". Otherwise I'd recommend Omar's suggestion. I believe that was the intention of the JEP 223 design. It will contain the version number of the JDK, the build number, and the additional (opt) part saying that this is a Debian build, with a Debian-specific version numbering of 1. /Magnus >> >> Matthias >> From nipa at codefx.org Fri Oct 27 11:29:06 2017 From: nipa at codefx.org (Nicolai Parlog) Date: Fri, 27 Oct 2017 13:29:06 +0200 Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> References: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: <2b7b62e3-01d2-a3ab-4471-b5cd5fe1fd03@codefx.org> Hi, many repliers see no reason to change the version-string scheme. I do. Mark wrote[1]: > Given the new release model, what is the best version scheme > for the Java SE Platform and the JDK? Since Java has a brand new version-string scheme[2], it makes sense to put this question into that context and rephrase it to: > Given the new release model, does JEP 223 still define the > best version scheme for the Java SE Platform and the JDK? Or even: > Given the new release model, which (possibly implicit) > assumptions of JEP 223 no longer apply? I think the answer lies here: > `$MAJOR` --- The major version number, incremented for a major > release that contains significant new features as specified in > a new edition of the Java SE Platform Specification With two to three years between major releases the assumption that they warrant a major version number increment is legit. Consequently, JDK engineers, JCP observers, and the general public know early on what the new version will be called and can use it in repository trees, issue trackers, announcements, discussions, etc. By releasing a new "major" version every six months it seems possible that, following JEP 223, some of them do not earn a major version number increment. (If everybody's sure that every six-month release "contains significant new features", then the rest of my argument is moot and JEP 223's scheme has no weakness after all.) The new version would be decided upon when the release enters rampdown phase, approx. three months before the release. Forecasting names for the release after next or even further becomes very unreliable. This is obviously a severe inconvenience for the people working on Java and I am sure that, out of necessity, they will start referencing versions by their release date. Where they used to discuss "Will $feature make it into Java 10?" it will now be "Will $feature make it into the September 2018 release?" Similarly if repository trees are named by releases (will that still happen?) or issues are targeted for releases that are more than three months into the future, they _have to_ use release dates. When I began writing this mail, I only saw that as a possibility, but by now I have convinced myself that "internally" (at Oracle and on the mailing lists) releases will mostly be referenced by date unless the new version-scheme is 100% predictable (which JEP 223 isn't). (Interestingly enough, that puts me at odds with at least two proposals, which argue to use release dates externally and "proper semver" internally. I think that puts the cart before the horse because _internal_ use is driving the "release date as version string" idea, not external.) Magnus wrote[3]: > The question you're discussing here is "what is convenient for the developers and release managers of OpenJDK", not "what is convenient for the users of OpenJDK". The number of the former outweight the latter in orders of magnitute, and so it's the only impact that's relevant in this discussion. The apparently clear distinction between "JDK developers" and "JDK users" is misleading. How do users learn about the new release? By reading the great "State of the ..." documents (written by JDK developers), the mailing lists (JDK devs and those close by), articles/tweets/... (same people), or by attending talks (same people). The vernacular of referencing versions by their release date will seep into "user space" and this is even advisable when talking about releases more than a few months into the future. (Nota bene: We just decided that we will move our product's baseline from Java 8 to the Sep 2018 release. What will it be called? Nobody knows, but we nonetheless have to reference it when documenting that decision.) Taken together, I'd say that does not render the "orders of magnitute" argument moot, but it does put it into perspective and should make clear that no matter what version-scheme is eventually picked, users will hear a lot about those release dates anyway. With all of that said, this is not an argument for naming versions purely after release dates. The situations I described so far just mean that release dates will become much more important in the months leading up to and immediately following a release. And I think that makes it fair to consider whether the release date is the better version. Personally, I still think it isn't. I'm convinced that in the long term users will be better served with a well-known version-string scheme like the one JEP 223 defines, but others have made that argument already. Ideally a variant could be found that marries the two pieces of information (release date and semantic version), but (A) I have no good idea and (B); > Please don't say which version-number scheme you prefer for > Java SE and the JDK. :) so long ... Nicolai [1]: http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000018.html [2]: http://openjdk.java.net/jeps/223 [3]: http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000059.html -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From Roger.Riggs at Oracle.com Fri Oct 27 14:50:26 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 27 Oct 2017 10:50:26 -0400 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <0957a041-6f2f-6625-b455-bab96c34b177@Oracle.com> Vote: Yes On 10/23/2017 1:23 PM, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. From daniel.fuchs at oracle.com Fri Oct 27 15:14:31 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 27 Oct 2017 16:14:31 +0100 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: Vote: yes best regards, -- daniel On 23/10/2017 18:23, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. From karen.kinnear at oracle.com Fri Oct 27 16:17:07 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 27 Oct 2017 12:17:07 -0400 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: Vote: yes thanks, Karen > On Oct 23, 2017, at 1:23 PM, Vladimir Kozlov wrote: > > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT compiler group. Before that he worked on embedded JVM - he did a lot contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 ports which were pushed into Open JDK year ago. He also contributed 17 changes into AOT project during its development. Unfortunately both projects, ARM and AOT, have only one combined changeset when they were pushed into Open JDK. In addition to that Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) From cthalinger at twitter.com Mon Oct 30 11:20:33 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 30 Oct 2017 12:20:33 +0100 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <89494A2E-C2A0-4947-B7F0-1F43877EDDC7@twitter.com> Vote: yes > On Oct 23, 2017, at 7:23 PM, Vladimir Kozlov wrote: > > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT compiler group. Before that he worked on embedded JVM - he did a lot contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 ports which were pushed into Open JDK year ago. He also contributed 17 changes into AOT project during its development. Unfortunately both projects, ARM and AOT, have only one combined changeset when they were pushed into Open JDK. In addition to that Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) From per.liden at oracle.com Mon Oct 30 15:14:29 2017 From: per.liden at oracle.com (Per Liden) Date: Mon, 30 Oct 2017 16:14:29 +0100 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <05d151e9-8792-1495-d7d8-5bbaf01b3a61@oracle.com> Vote: Yes /Per On 2017-10-23 19:23, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and ARM32 > ports which were pushed into Open JDK year ago. He also contributed 17 > changes into AOT project during its development. Unfortunately both > projects, ARM and AOT, have only one combined changeset when they were > pushed into Open JDK. In addition to that Dean contributed 33 changes > directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) > From daniel.daugherty at oracle.com Mon Oct 30 18:51:48 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 30 Oct 2017 14:51:48 -0400 Subject: CFV: New JDK Reviewer: Dean Long In-Reply-To: References: Message-ID: <160e6766-b4cc-ccde-ee50-0678bc77d3ce@oracle.com> Vote: yes Dan On 10/23/17 1:23 PM, Vladimir Kozlov wrote: > I hereby nominate Dean Long (dlong) to JDK Reviewer. > > This is long overdue. Dean Long currently is member of HotSpot JIT > compiler group. Before that he worked on embedded JVM - he did a lot > contributions (the exact count is lost) into Oracle's AARCH64 and > ARM32 ports which were pushed into Open JDK year ago. He also > contributed 17 changes into AOT project during its development. > Unfortunately both projects, ARM and AOT, have only one combined > changeset when they were pushed into Open JDK. In addition to that > Dean contributed 33 changes directly to Open JDK Project [3]. > > Votes are due by 6 November 2017, 10:00 am PT. > > Only current JDK Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk10/hs/log?revcount=100&rev=(keyword(%22dean.long at oracle.com%22)+or+author(dlong)) > > From mark.reinhold at oracle.com Mon Oct 30 21:14:03 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 30 Oct 2017 14:14:03 -0700 Subject: Proposed schedule for JDK 18.3 In-Reply-To: <20171011171710.CE586D257D@eggemoggin.niobe.net> References: <20171011171710.CE586D257D@eggemoggin.niobe.net> Message-ID: <20171030141403.674603740@eggemoggin.niobe.net> 2017/10/11 10:17:10 -0700, mark.reinhold at oracle.com: > Here is a proposed schedule: > > 2017/12/14 Rampdown Phase One > 2018/01/11 All Tests Run > 2018/01/18 Rampdown Phase Two > 2018/02/22 Final Release Candidate > 2018/03/20 General Availability > > The milestone definitions are the same as for JDK 8 [1]. > > ... > > Comments from JDK Committers are welcome, as are reasoned objections. > If no such objections are raised by 18:00 UTC next Wednesday, 18 October, > or if they're raised and then satisfactorily answered, then per the JEP > 2.0 process proposal [2] this will be adopted as the schedule for JDK > 18.3 (or whatever we wind up calling it). Hearing no objections, this is now the schedule for JDK $NEXT. - Mark