LTS for public releases

Mario Torre neugens.limasoftware at gmail.com
Thu Nov 9 13:46:13 UTC 2017


2017-11-08 18:31 GMT+01:00 Stephen Colebourne <scolebourne at joda.org>:
> On 8 November 2017 at 16:31, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>> Well, that page is about Oracle's binaries, not OpenJDK in general.
>> It's important not to confuse the two.
>>
>> It may well be that Oracle don't provide public binaries of LTS releases,
>> but there's nothing stopping anyone else from doing so and I would
>> expect that to continue as it does now in various distributions.
>
> I don't think this game of "well someone else might support it" is at
> all helpful to the wider community.
>
> Architects/senior devs need to know that the code they are writing now
> can run on a supported platform for at least a few years after they
> finish coding it. This has been one of the critical factors in Java's
> success.
>
> What is actually being promised is ridiculously woolly by comparison.
> Oracle might provide 3 years of public updates on LTS for $free, or
> they might not. Red Hat might provide some LTS's or they might not.
> Red Hat LTS's might align with Oracle's LTS, or they might not. Some
> other random group of "OpenJDK community" might turn up and do
> something, or it might not.
>
> No certainty. No ability to plan. Its a mess.

Can't see why is that. No one of the involved party has any interest
in devaluating the benefit of Java releases. LTS will behave as they
do now, non LTS will be supported for as long as they are alive.
Popular version may end up being supported for longer. This is already
the case today, Java 6 has been around for far longer than anyone
wanted, for example.

Obviously, syncing up on LTS makes sense for all the vendors, since it
provides a standard base for longer term standards, rather than each
one doing their own thing.

The goal of short term release is not to kill compatibility, if any,
features will be introduced incrementally which will lower the risk of
incompatible changes and offer a way of correcting them in no less
that one short release cycle, I can see only benefit here. This is not
not possible with the long term release scheme, where 10 or more new
features end up being pushed in a monolithic upgrade every few years,
without a real upgrade plan (which means we end up with older versions
supported forever).

The plan is simple, there one LTS (that meet the demand of customer
that value stability) every fixed amount of time, and then there are
short term releases every shorter amount of time, developers should
use them to develop and test their software, while use the LTS in
production systems that need long term support. It really can't get
any easier and fits both worlds, no one is left behind.

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