Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37385 > unrolled thread

Big changes are coming to Java SE release cycle

Back to article view | Back to comp.lang.java.programmer

Contents

  Big changes are coming to Java SE release cycle Arne Vajhøj <arne@vajhoej.dk> - 2017-09-11 18:46 -0400
    Re: Big changes are coming to Java SE release cycle Arne Vajhøj <arne@vajhoej.dk> - 2017-09-11 18:52 -0400
      Re: Big changes are coming to Java SE release cycle Sebastian <nowhere@nirvana.org> - 2017-09-12 23:37 +0200
        Re: Big changes are coming to Java SE release cycle Arne Vajhøj <arne@vajhoej.dk> - 2017-09-12 20:01 -0400

#37385 — Big changes are coming to Java SE release cycle

https://mreinhold.org/blog/forward-faster

<quote>
     Taking inspiration from the release models used by other platforms 
and by various operating-system distributions, I propose that after Java 
9 we adopt a strict, time-based model with a new feature release every 
six months, update releases every quarter, and a long-term support 
release every three years.

     Feature releases can contain any type of feature, including not 
just new and improved APIs but also language and JVM features. New 
features will be merged only when they’re nearly finished, so that the 
release currently in development is feature-complete at all times. 
Feature releases will ship in March and September of each year, starting 
in March of 2018.

     Update releases will be strictly limited to fixes of security 
issues, regressions, and bugs in newer features. Each feature release 
will receive two updates before the next feature release. Update 
releases will ship quarterly in January, April, July, and October, as 
they do today.

     Every three years, starting in September of 2018, the feature 
release will be a long-term support release. Updates for these releases 
will be available for at least three years and quite possibly longer, 
depending upon your vendor.
</quote>

Arne

[toc] | [next] | [standalone]

#37386

On 9/11/2017 6:46 PM, Arne Vajhøj wrote:
> https://mreinhold.org/blog/forward-faster
> 
> <quote>
>      Taking inspiration from the release models used by other platforms 
> and by various operating-system distributions, I propose that after Java 
> 9 we adopt a strict, time-based model with a new feature release every 
> six months, update releases every quarter, and a long-term support 
> release every three years.
> 
>      Feature releases can contain any type of feature, including not 
> just new and improved APIs but also language and JVM features. New 
> features will be merged only when they’re nearly finished, so that the 
> release currently in development is feature-complete at all times. 
> Feature releases will ship in March and September of each year, starting 
> in March of 2018.
> 
>      Update releases will be strictly limited to fixes of security 
> issues, regressions, and bugs in newer features. Each feature release 
> will receive two updates before the next feature release. Update 
> releases will ship quarterly in January, April, July, and October, as 
> they do today.
> 
>      Every three years, starting in September of 2018, the feature 
> release will be a long-term support release. Updates for these releases 
> will be available for at least three years and quite possibly longer, 
> depending upon your vendor.
> </quote>

And:

http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html

<quote>
   - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to
     make it easier for developers to deploy Java applications to cloud
     environments.  We'll initially publish OpenJDK builds for Linux/x64,
     followed later by builds for macOS/x64 and Windows/x64.

   - We'll continue to ship proprietary "Oracle JDK" builds, which include
     "commercial features" [7] such as Java Flight Recorder and Mission
     Control [8], under a click-through binary-code license [9].  Oracle
     will continue to offer paid support for these builds.

   - After JDK 9 we'll open-source the commercial features in order to
     make the OpenJDK builds more attractive to developers and to reduce
     the differences between those builds and the Oracle JDK.  This will
     take some time, but the ultimate goal is to make OpenJDK and Oracle
     JDK builds completely interchangeable.
</quote>

Arne

[toc] | [prev] | [next] | [standalone]

#37400

Am 12.09.2017 um 00:52 schrieb Arne Vajhøj:
> On 9/11/2017 6:46 PM, Arne Vajhøj wrote:
>> https://mreinhold.org/blog/forward-faster
>>
>> <quote>
>>      Taking inspiration from the release models used by other
>> platforms and by various operating-system distributions, I propose
>> that after Java 9 we adopt a strict, time-based model with a new
>> feature release every six months, update releases every quarter, and a
>> long-term support release every three years.
>>
>>      Feature releases can contain any type of feature, including not
>> just new and improved APIs but also language and JVM features. New
>> features will be merged only when they’re nearly finished, so that the
>> release currently in development is feature-complete at all times.
>> Feature releases will ship in March and September of each year,
>> starting in March of 2018.
>>
>>      Update releases will be strictly limited to fixes of security
>> issues, regressions, and bugs in newer features. Each feature release
>> will receive two updates before the next feature release. Update
>> releases will ship quarterly in January, April, July, and October, as
>> they do today.
>>
>>      Every three years, starting in September of 2018, the feature
>> release will be a long-term support release. Updates for these
>> releases will be available for at least three years and quite possibly
>> longer, depending upon your vendor.
>> </quote>
>
> And:
>
> http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
>
> <quote>
>   - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to
>     make it easier for developers to deploy Java applications to cloud
>     environments.  We'll initially publish OpenJDK builds for Linux/x64,
>     followed later by builds for macOS/x64 and Windows/x64.
>
>   - We'll continue to ship proprietary "Oracle JDK" builds, which include
>     "commercial features" [7] such as Java Flight Recorder and Mission
>     Control [8], under a click-through binary-code license [9].  Oracle
>     will continue to offer paid support for these builds.
>
>   - After JDK 9 we'll open-source the commercial features in order to
>     make the OpenJDK builds more attractive to developers and to reduce
>     the differences between those builds and the Oracle JDK.  This will
>     take some time, but the ultimate goal is to make OpenJDK and Oracle
>     JDK builds completely interchangeable.
> </quote>
>
> Arne
>
>
These are very good decisions! Who would have thought I was going to 
like Oracle's stewardship of Java. This is going entirely in the right 
direction.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#37402

On 9/12/2017 5:37 PM, Sebastian wrote:
> Am 12.09.2017 um 00:52 schrieb Arne Vajhøj:
>> On 9/11/2017 6:46 PM, Arne Vajhøj wrote:
>>> https://mreinhold.org/blog/forward-faster
>>>
>>> <quote>
>>>      Taking inspiration from the release models used by other
>>> platforms and by various operating-system distributions, I propose
>>> that after Java 9 we adopt a strict, time-based model with a new
>>> feature release every six months, update releases every quarter, and a
>>> long-term support release every three years.
>>>
>>>      Feature releases can contain any type of feature, including not
>>> just new and improved APIs but also language and JVM features. New
>>> features will be merged only when they’re nearly finished, so that the
>>> release currently in development is feature-complete at all times.
>>> Feature releases will ship in March and September of each year,
>>> starting in March of 2018.
>>>
>>>      Update releases will be strictly limited to fixes of security
>>> issues, regressions, and bugs in newer features. Each feature release
>>> will receive two updates before the next feature release. Update
>>> releases will ship quarterly in January, April, July, and October, as
>>> they do today.
>>>
>>>      Every three years, starting in September of 2018, the feature
>>> release will be a long-term support release. Updates for these
>>> releases will be available for at least three years and quite possibly
>>> longer, depending upon your vendor.
>>> </quote>
>>
>> And:
>>
>> http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
>>
>> <quote>
>>   - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to
>>     make it easier for developers to deploy Java applications to cloud
>>     environments.  We'll initially publish OpenJDK builds for Linux/x64,
>>     followed later by builds for macOS/x64 and Windows/x64.
>>
>>   - We'll continue to ship proprietary "Oracle JDK" builds, which include
>>     "commercial features" [7] such as Java Flight Recorder and Mission
>>     Control [8], under a click-through binary-code license [9].  Oracle
>>     will continue to offer paid support for these builds.
>>
>>   - After JDK 9 we'll open-source the commercial features in order to
>>     make the OpenJDK builds more attractive to developers and to reduce
>>     the differences between those builds and the Oracle JDK.  This will
>>     take some time, but the ultimate goal is to make OpenJDK and Oracle
>>     JDK builds completely interchangeable.
>> </quote>

> These are very good decisions! Who would have thought I was going to 
> like Oracle's stewardship of Java. This is going entirely in the right 
> direction.

I think the big positive is that it sends a clear signal that
Oracle want to push Java forward full speed. That is good.

I like:
- more frequent releases
- the full sync between Oracle Java and OpenJDK

I do not care that Solaris and 32 bit Windows are
becoming second class OS'es.

I am not sure that I like the short term and long term
versions model. I think that is more smart than good.

But overall pretty good.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web