Version-string schemes for the Java SE Platform and the JDK

Mario Torre neugens.limasoftware at gmail.com
Fri Oct 20 12:57:03 UTC 2017


2017-10-19 17:08 GMT+02:00  <mark.reinhold at oracle.com>:

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/


More information about the jdk-dev mailing list