An impassioned plea on version numbers

[Chris Newland]

+1 to this suggestion of spec.date

Regarding https://twitter.com/rafaelcodes/status/905474910599905280 I
would appreciate if there was a published mapping between the external
release version and the various internal version numbers;

Class file version
HotSpot version (to identify log formats)
Security baseline

Ideally (imho) these would increment only when there was an external
effect that tools needed to know about.

Kind regards,

Chris
--
@chriswhocodes | https://github.com/AdoptOpenJDK/jitwatch

On Thu, October 12, 2017 06:22, Peter Lawrey wrote:
> I favour the version of Java to change when there is a break in backward
> compability in the Java language. Ie code written for 18.3 wont compile on
>  9 if var is used. Bumping the major version without a major changing in
> the spec conveys less information imho.
>
> I would favour
>
>
> Java spec version counter.date of release.
>
>
> Unless the plan is to break backward compatability every 6 months
> assuming you utilise the latest language featues.
>
> I guess the question is if you don't know when a java language spec might
>  change but you want to announce version numbers years in advance and
> stick to them. Thus the intent is not to imply anything by the version
> number other than a date.
>
> Regards Peter.
>
>
> On 11 Oct. 2017 6:49 pm, "Aleksey Shipilev" <shade at redhat.com> wrote:
>
>
>> On 09/22/2017 08:04 PM, Stephen Colebourne wrote:
>>
>>> I propose that versions should simply increase incrementally.
>>> March 2018  - v10
>>> September 2018 - v11
>>> March 2019 - v12
>>> September 2019 - v13
>>>
>>
>> Yes, that makes more sense than year.month. Maybe x.y.z semver-like
>> scheme is better, and 9.0 already fits there. I have been living with the
>> proposed scheme in my mind, on the off-chance the novelty of it
>> displeases me, but no, it does not bode well. Quick! What is the version
>> of the next LTS release? And the one after that? Can you do it without a
>> chart?
>>
>> Actually, I can't even do that for Ubuntu. I have to remember that
>> Ubuntu
>> 16.04 is LTS, not the
>> 16.10. But I did downloaded and installed some Ubuntu images only much
>> later realizing they were not LTS, because those minor numbers are
>> different. Remembering that only e.g. Java 8.*, and Java 10.*,
>> and Java 12.* are LTSes would be much, much easier.
>>
>> Another perspective: current proposal answers "when the JDK was
>> released", which is not the same as "what the JDK is". It might appear
>> easier for JDK developers who have JDK roadmaps firmly committed in their
>> heads, but not for ordinary folks.
>>
>> Mark promised a more substantial reply after JavaOne. No pressure ;)
>>
>>
>> Thanks,
>> -Aleksey
>>
>>
>>
>