An impassioned plea on version numbers

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

An impassioned plea on version numbers

Stephen Colebourne-2
While I am super happy to see Java 9 released I remain strongly opposed to
the proposed version number scheme from now on. Here is why:

1) The vast majority of existing code that needs to know the version of
Java only cares about the major digit. For example online CI like
Travis/Shippable, build tools like Maven, community projects that target
different behaviour to different releases, all only consider the version to
be a single number. This is far more disruptive than changing 1.9 to 9
because these pieces of code would need to handle two important numbers (18
and 3), not one.. Forcing all this code to change is simply not a good
choice.

2) No version is more important than any other going forward in terms of
features. A new language change (the most disruptive) could occur in March
or September. It will require a developer to specify two numbers (18.3) to
say what release LVTI is in for example. Given the strong link to semantic
version numbering in developers minds, the numbering scheme simply does not
make sense. A major new language change in a minor point release??!! Being
able to say quickly and easily what version a new language feature is in is
vital, and 18.3 / 18.9 obscures that horribly.

3) While the LTS release is important to Oracle and big business, it will
be pretty unimportant to the community. It should not be the basis of the
version.

4) The proposed scheme appears to be a lot about forcing through the change
within Oracle processes, based on the idea that if it is named after a
month then no one can ask it to slip. However true that fear might be, it
does not justify developers having to face a sub-standard version scheme.

5) Java is not an OS like Ubuntu. The version of Java is referred to all
the time - it is front and centre in discussions about Java. Even
recruiters talk about it! It needs to be simple and straightforward for all
the tasks it is used for - a year/month scheme is unusual and unexpected.


I propose that versions should simply increase incrementally.
 March 2018  - v10
 September 2018 - v11
 March 2019 - v12
 September 2019 - v13
and so on.

Stephen
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

mark.reinhold
2017/9/22 11:04:05 -0700, Stephen Colebourne <[hidden email]>:
> While I am super happy to see Java 9 released I remain strongly opposed to
> the proposed version number scheme from now on. Here is why:
>
> ...

Thanks for your impassioned plea.  You make some reasonable arguments.
I'll reply at length after JavaOne.

- Mark
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Peter Lawrey-3
In reply to this post by Stephen Colebourne-2
A single number approach might be

183
189
193
199
203
209

Given we have 3 digit updates now it might not matter as much.

However 10, 11, 12 seems like a fine suggestion.

Regards Peter

On 22 Sep. 2017 21:04, "Stephen Colebourne" <[hidden email]> wrote:

While I am super happy to see Java 9 released I remain strongly opposed to
the proposed version number scheme from now on. Here is why:

1) The vast majority of existing code that needs to know the version of
Java only cares about the major digit. For example online CI like
Travis/Shippable, build tools like Maven, community projects that target
different behaviour to different releases, all only consider the version to
be a single number. This is far more disruptive than changing 1.9 to 9
because these pieces of code would need to handle two important numbers (18
and 3), not one.. Forcing all this code to change is simply not a good
choice.

2) No version is more important than any other going forward in terms of
features. A new language change (the most disruptive) could occur in March
or September. It will require a developer to specify two numbers (18.3) to
say what release LVTI is in for example. Given the strong link to semantic
version numbering in developers minds, the numbering scheme simply does not
make sense. A major new language change in a minor point release??!! Being
able to say quickly and easily what version a new language feature is in is
vital, and 18.3 / 18.9 obscures that horribly.

3) While the LTS release is important to Oracle and big business, it will
be pretty unimportant to the community. It should not be the basis of the
version.

4) The proposed scheme appears to be a lot about forcing through the change
within Oracle processes, based on the idea that if it is named after a
month then no one can ask it to slip. However true that fear might be, it
does not justify developers having to face a sub-standard version scheme.

5) Java is not an OS like Ubuntu. The version of Java is referred to all
the time - it is front and centre in discussions about Java. Even
recruiters talk about it! It needs to be simple and straightforward for all
the tasks it is used for - a year/month scheme is unusual and unexpected.


I propose that versions should simply increase incrementally.
 March 2018  - v10
 September 2018 - v11
 March 2019 - v12
 September 2019 - v13
and so on.

Stephen
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Nicolai Parlog
In reply to this post by mark.reinhold
 Hi,

I appreciate the push towards releasing Java more often and the same
goes for reducing the differences between Oracle JDK and Open JDK as
well as the new licensing details. These are all great decisions moving
Java into the right direction!

Alas, discussions usually focus on disagreements and I want to chime in
on the one thing that I don't agree with: the versioning scheme. Here's
what I wrote elsewhere[1]...

## Disagreement

One problem with year.month is that it looks like semantic versioning
but isn't - 18.9 might have more severe changes than 19.3, yet the
latter incremented the "major version", while the former did not. And it
not only looks like semver, the new Java 9 API even claims it is[2].

Also, every newcomer has to be taught about this, so they don’t go
looking for 18.4. And heavens forbid one release is not on time, so
there’s a 18.4 after all. Or the release months change because nobody
works over the summer, so x.9 never had any interesting new features.
(At least that would reestablish semantic versioning.)

Then there’s the risk of polluting the “version space” with artificially
high numbers. Java already changed the version schema a few times, most
recently on September 21st which was still in the future when this
proposal was made, so it sounds unrealistic to assume that this change
is the last one. But there’s no way but forward from 20.3 — you can
hardly go back to 13, explain to your users why that’s better than 20.3
and then at some point awkwardly jump from 17 over 18.3–20.3 and
continue with 21.

No, I don’t think that’s a good idea.

## Alternative proposals

Why not stick to the current scheme and increment the minor version with
every feature release unless it contains considerable language/JVM
changes, in which case the major version gets bumped.

To pick a few examples from history, Java 6 and 7 might have been 5.1
and 5.2 and, leaving the module system aside, Java 9 could have been
Java 8.1 because the few language changes don’t require the bump to 9.
Examples for major upcoming language changes would be generic
specialization and value types from Project Valhalla. Amber’s proposals,
on the other hand, could be seen on either side — I’d file enhanced
enums and lambda leftovers under minor changes whereas local variable
type inference, pattern matching, and data classes constitute major ones.

This would of course lead to discussions about how much impact a
language change might have and whether it deserves a major version bump
or not, but I don’t see any problems with that — the expected impact of
a feature and how much it would change the code we write are already
being discussed extensively anyways.

If all that’s no good and the year needs to be in there, I have a final
suggestion: Go with year.increment (18.1, 18.2, ...) like JetBrains does
for IntelliJ et al. This would give more leeway for adding, omitting, or
rescheduling releases or the entire release schedule without baking that
into the version.

 so long ... Nicolai


[1]
https://medium.com/codefx-weekly/radical-new-plans-for-java-5f237ab05b0#b2dc
[2]
http://download.java.net/java/jdk9/docs/api/java/lang/Runtime.Version.html#major



On 25.09.2017 15:56, [hidden email] wrote:

> 2017/9/22 11:04:05 -0700, Stephen Colebourne <[hidden email]>:
>> While I am super happy to see Java 9 released I remain strongly opposed to
>> the proposed version number scheme from now on. Here is why:
>>
>> ...
>
> Thanks for your impassioned plea.  You make some reasonable arguments.
> I'll reply at length after JavaOne.
>
> - Mark
>

--

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
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Andrew Haley
In reply to this post by Stephen Colebourne-2
On 22/09/17 19:04, Stephen Colebourne wrote:
> I propose that versions should simply increase incrementally.
>  March 2018  - v10
>  September 2018 - v11
>  March 2019 - v12
>  September 2019 - v13

I'd prefer 18r1, 18r2, 19r1, etc.  18.1 is OK, but too much like a
"conventional" version number.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Peter Lawrey-3
It's worth noting the version is likely to be

1.10.0_1
1.11.0_1

or

1.18.3_1
1.18.9_1
1.19.3_1

I am not sure adding r1, r2 really helps. Perhaps a combination would work

1.10.18_300
1.10.18_900
1.10.19_300
1.11.19_900
1.11.20_300

or

1.10.183_1
1.10.189_1
1.10.193_1
1.11.199_1
1.11.203_1

This way the middle/major-ish version shows changes in the language and the
minor version show updates in the libraries/JSRs included.





On 27 September 2017 at 16:40, Andrew Haley <[hidden email]> wrote:

> On 22/09/17 19:04, Stephen Colebourne wrote:
> > I propose that versions should simply increase incrementally.
> >  March 2018  - v10
> >  September 2018 - v11
> >  March 2019 - v12
> >  September 2019 - v13
>
> I'd prefer 18r1, 18r2, 19r1, etc.  18.1 is OK, but too much like a
> "conventional" version number.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Andrew Haley
On 27/09/17 16:31, Peter Lawrey wrote:

> It's worth noting the version is likely to be
>
> 1.10.0_1
> 1.11.0_1
>
> or
>
> 1.18.3_1
> 1.18.9_1
> 1.19.3_1

Why do you say that?

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Omair Majid
In reply to this post by Stephen Colebourne-2
* Stephen Colebourne <[hidden email]> [2017-09-22 14:06]:
> 5) Java is not an OS like Ubuntu. The version of Java is referred to all
> the time - it is front and centre in discussions about Java. Even
> recruiters talk about it! It needs to be simple and straightforward for all
> the tasks it is used for - a year/month scheme is unusual and unexpected.

And if anyone thinks the Ubuntu versioning system is simple, a quick
google shows many documents where users are confused. For example,
these docs refer to Ubuntu 16. Not 16.04 or 16.10, just 16.

https://github.com/openstreetmap/Nominatim/blob/master/docs/Install-on-Ubuntu-16.md
http://www.geoffstratton.com/spamassassin-3-ubuntu-16
https://www.upcloud.com/support/installing-snort-on-ubuntu/
https://community.qualys.com/thread/17402-qualys-cloud-agent-and-ubuntu-16
https://www.vpsserver.com/community/tutorials/49/installing-drupal-on-ubuntu-16-vps-server/
http://www.aerospike.com/docs/client/c/install/ubuntu16.html

We should not be surprised if the same happens with Java: instead of
18.3 or 18.9, people will be taking about Java 18.

Thanks,
Omair

--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Peter Lawrey-3
In reply to this post by Andrew Haley
I am assuming a minimum of changes to the format of the current internal
Java version

$ java -version
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

With a recent version of Java 8 update 144, being 1.8.0_144 internally.


On 27 September 2017 at 19:12, Andrew Haley <[hidden email]> wrote:

> On 27/09/17 16:31, Peter Lawrey wrote:
> > It's worth noting the version is likely to be
> >
> > 1.10.0_1
> > 1.11.0_1
> >
> > or
> >
> > 1.18.3_1
> > 1.18.9_1
> > 1.19.3_1
>
> Why do you say that?
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Sven Reimers
This format already changed for 9.

Sven

Am 28.09.2017 08:43 schrieb "Peter Lawrey" <[hidden email]>:

> I am assuming a minimum of changes to the format of the current internal
> Java version
>
> $ java -version
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>
> With a recent version of Java 8 update 144, being 1.8.0_144 internally.
> ᐧ
>
> On 27 September 2017 at 19:12, Andrew Haley <[hidden email]> wrote:
>
> > On 27/09/17 16:31, Peter Lawrey wrote:
> > > It's worth noting the version is likely to be
> > >
> > > 1.10.0_1
> > > 1.11.0_1
> > >
> > > or
> > >
> > > 1.18.3_1
> > > 1.18.9_1
> > > 1.19.3_1
> >
> > Why do you say that?
> >
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Ismael Juma
That's right:

$ java -version
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)

Ismael

On Thu, Sep 28, 2017 at 9:17 AM, Sven Reimers <[hidden email]>
wrote:

> This format already changed for 9.
>
> Sven
>
> Am 28.09.2017 08:43 schrieb "Peter Lawrey" <[hidden email]>:
>
> > I am assuming a minimum of changes to the format of the current internal
> > Java version
> >
> > $ java -version
> > java version "1.8.0_144"
> > Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> > Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
> >
> > With a recent version of Java 8 update 144, being 1.8.0_144 internally.
> > ᐧ
> >
> > On 27 September 2017 at 19:12, Andrew Haley <[hidden email]> wrote:
> >
> > > On 27/09/17 16:31, Peter Lawrey wrote:
> > > > It's worth noting the version is likely to be
> > > >
> > > > 1.10.0_1
> > > > 1.11.0_1
> > > >
> > > > or
> > > >
> > > > 1.18.3_1
> > > > 1.18.9_1
> > > > 1.19.3_1
> > >
> > > Why do you say that?
> > >
> > > --
> > > Andrew Haley
> > > Java Platform Lead Engineer
> > > Red Hat UK Ltd. <https://www.redhat.com>
> > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Nicolai Parlog
In reply to this post by Sven Reimers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Which I find truly funny, because when the year.month scheme was
proposed, 9.0 was still in the future.



On 28.09.2017 10:17, Sven Reimers wrote:

> This format already changed for 9.
>
> Sven
>
> Am 28.09.2017 08:43 schrieb "Peter Lawrey"
> <[hidden email]>:
>
>> I am assuming a minimum of changes to the format of the current
>> internal Java version
>>
>> $ java -version java version "1.8.0_144" Java(TM) SE Runtime
>> Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server
>> VM (build 25.144-b01, mixed mode)
>>
>> With a recent version of Java 8 update 144, being 1.8.0_144
>> internally. ᐧ
>>
>> On 27 September 2017 at 19:12, Andrew Haley <[hidden email]>
>> wrote:
>>
>>> On 27/09/17 16:31, Peter Lawrey wrote:
>>>> It's worth noting the version is likely to be
>>>>
>>>> 1.10.0_1 1.11.0_1
>>>>
>>>> or
>>>>
>>>> 1.18.3_1 1.18.9_1 1.19.3_1
>>>
>>> Why do you say that?
>>>
>>> -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd.
>>> <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD
>>> 6035 332F A671
>>>
>>
>

- --

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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEB4Ehg6tSyQFzO00OyjutLpzM1QkFAlnOG6wACgkQyjutLpzM
1QkDOQ/+O64by3nrJpVrkF2aI+gJd6jdG0S9ptMb0uKr1MbE1jZLjhc1qeDnKlWs
UYrj6EbuhVciA8HQuJuEOBdpvNO++x5BocJKYQUjztKtE0bbSP3DBlkdEljeAncJ
ooWWzilJi33Aj55BtjfMBkBmdFJYBXS9IDLaS0e9jVA73qO/bVbpooz73b5ch/eL
FQLgB1cdKtSQy1199UwWa9O/HTNCSGPzLIeJw+MJc+/05mKs73XdtiuD/qx4A28u
eutNUwFmDVP4ytQAqhgo6ia2ZnFYrkSkqg79BHfWOq6t0hQk/+EkaEkobzBxBJFx
i1yEKkzc/9WCbiuXvx92rAueCuKBhro9eOMEgINELJ53MAx7fJkdZMfBLT5IANgN
82K7JRHNLCMJCdnBTseYJ8UM6svdfiGLwekkhyQm7t5qGjMzUIcALz/5cqq+QOGk
cebzyr1ellHcRk0mxVU0sQ6v3CTJ+nnoCBLui4RfONjiAX3ggq9gST55ibahcfii
VW6sGbrwAAAEo7LJ1FPMPDqMUokV0KT96G5WW/r0T9IyTJlgGyPBONKPANRqAd/4
60AiwGEAhUGvyiPE5GY6P6sgDi/77Nuuln5zuRmL21II5tXChfEOvx6PA74fzFso
0IX6lVFPOyK2GJx2qFPk6y0Vs2Gui5ObdD5WGvz4fZLLIYzn23o=
=t4cD
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Aleksey Shipilev-4
In reply to this post by Stephen Colebourne-2
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

Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Peter Lawrey-3
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" <[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Daniel Latrémolière
In reply to this post by Nicolai Parlog
Another possibility (more developer-friendly in my opinion) could be:

  * increase minor version with each feature release (currently expected
    each six months).
  * increase major version / reinit minor version with each core feature
    removal [1] (e.g. serialization, finalizers).

My two cents,

Daniel.


[1]: Never say never.

Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

Chris Newland
In reply to this post by Peter Lawrey-3
+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" <[hidden email]> 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
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: An impassioned plea on version numbers

mark.reinhold
In reply to this post by mark.reinhold
2017/9/25 6:56:51 -0700, [hidden email]:
> 2017/9/22 11:04:05 -0700, Stephen Colebourne <[hidden email]>:
>> While I am super happy to see Java 9 released I remain strongly opposed to
>> the proposed version number scheme from now on. Here is why:
>>
>> ...
>
> Thanks for your impassioned plea.  You make some reasonable arguments.
> I'll reply at length after JavaOne.

I've replied over on the jdk-dev list:

  http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html

I suggest we continue the discussion there, rather than here.

- Mark