Accelerating the JDK release cadence

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

Accelerating the JDK release cadence

mark.reinhold
Over on my blog today I've argued that Java needs to move forward faster.
To achieve that I've proposed that the Java SE Platform and the JDK shift
from the historical feature-driven release model to 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:

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

Here are some initial thoughts on how we might implement this proposal
here in the OpenJDK Community.  Comments and questions about both the
proposal and its implementation are welcome on this list.

Rather than create a brand new "JDK $N" Release Project every six months,
I suggest that we create a single long-running "JDK" Release Project to
host the main-line code base and produce the feature releases.  Similarly,
let's create a single long-running "JDK Updates" Project to produce the
update releases, for the most recent feature release and the current
long-term support release.

Two long-running Projects will save some administrative overhead, and also
eliminate the confusion that regularly arises when someone is a Committer
to JDK $N but not JDK $N + 1.  (We could consider just one long-running
Project, but two makes more sense since since the two types of releases
will have different policies, content, schedules, and leadership.)

The new JDK Project will run a bit differently than the past "JDK $N"
Projects:

  - The main development line will always be open but fixes, enhancements,
    and features will be merged only when they're nearly finished.  The
    main line will be Feature Complete [1] at all times.

  - We'll fork the main line into a release-stabilization branch three
    months before the GA date of the next feature release.  That branch
    will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2
    [3] a month later, and then enter the Release Candidate phase [4] a
    month after that.  (Whether the branch is another repository or an
    actual Mercurial branch is a detail we can figure out later.)

  - We'll continue to use the JEP Process [5] for new features and other
    significant changes.  The bar to target a JEP to a specific release
    will, however, be higher since the work must be Feature Complete in
    order to go in.  Owners of large or risky features will be strongly
    encouraged to split such features up into smaller and safer parts, to
    integrate earlier in the release cycle, and to publish separate lines
    of early-access builds prior to integration.

The JDK Updates Project will run in much the same way as the past "JDK $N"
Updates Projects, though update releases will be strictly limited to fixes
of security issues, regressions, and bugs in newer features.

Related to this proposal, we at Oracle intend to make a few changes in
what we do:

  - 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.

  - Finally, for the long term we'll work with other OpenJDK contributors
    to establish an open build-and-test infrastructure.  This will make
    it easier to publish early-access builds for features in development,
    and eventually make it possible for the OpenJDK Community itself to
    publish authoritative builds of the JDK.

So ... that's a lot of proposed change, and there are (obviously!) many
details to work out.  Comments?  Questions?

- Mark


[1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
[2] http://openjdk.java.net/projects/jdk9/rdp-1
[3] http://openjdk.java.net/projects/jdk9/rdp-2
[4] http://openjdk.java.net/projects/jdk9/rc
[5] http://openjdk.java.net/jeps/0
[6] http://openjdk.java.net/legal/gplv2+ce.html
[7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html
[8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
[9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Stephen Colebourne-2
I'm glad to see this happen. In general it seems fine (although I'm
still looking forward to OpenJDK on git ;-)

My only comment is the proposed version numbers. IMO, year-based
versions don't work well, who wants Java to be like Windows 95?

I'd suggest a simple incrementing number - like Chrome - is quite
sufficient for the problem - 10, 11, 12, 13

Stephen


On 6 September 2017 at 15:49,  <[hidden email]> wrote:

> Over on my blog today I've argued that Java needs to move forward faster.
> To achieve that I've proposed that the Java SE Platform and the JDK shift
> from the historical feature-driven release model to 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:
>
>   https://mreinhold.org/blog/forward-faster
>
> Here are some initial thoughts on how we might implement this proposal
> here in the OpenJDK Community.  Comments and questions about both the
> proposal and its implementation are welcome on this list.
>
> Rather than create a brand new "JDK $N" Release Project every six months,
> I suggest that we create a single long-running "JDK" Release Project to
> host the main-line code base and produce the feature releases.  Similarly,
> let's create a single long-running "JDK Updates" Project to produce the
> update releases, for the most recent feature release and the current
> long-term support release.
>
> Two long-running Projects will save some administrative overhead, and also
> eliminate the confusion that regularly arises when someone is a Committer
> to JDK $N but not JDK $N + 1.  (We could consider just one long-running
> Project, but two makes more sense since since the two types of releases
> will have different policies, content, schedules, and leadership.)
>
> The new JDK Project will run a bit differently than the past "JDK $N"
> Projects:
>
>   - The main development line will always be open but fixes, enhancements,
>     and features will be merged only when they're nearly finished.  The
>     main line will be Feature Complete [1] at all times.
>
>   - We'll fork the main line into a release-stabilization branch three
>     months before the GA date of the next feature release.  That branch
>     will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2
>     [3] a month later, and then enter the Release Candidate phase [4] a
>     month after that.  (Whether the branch is another repository or an
>     actual Mercurial branch is a detail we can figure out later.)
>
>   - We'll continue to use the JEP Process [5] for new features and other
>     significant changes.  The bar to target a JEP to a specific release
>     will, however, be higher since the work must be Feature Complete in
>     order to go in.  Owners of large or risky features will be strongly
>     encouraged to split such features up into smaller and safer parts, to
>     integrate earlier in the release cycle, and to publish separate lines
>     of early-access builds prior to integration.
>
> The JDK Updates Project will run in much the same way as the past "JDK $N"
> Updates Projects, though update releases will be strictly limited to fixes
> of security issues, regressions, and bugs in newer features.
>
> Related to this proposal, we at Oracle intend to make a few changes in
> what we do:
>
>   - 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.
>
>   - Finally, for the long term we'll work with other OpenJDK contributors
>     to establish an open build-and-test infrastructure.  This will make
>     it easier to publish early-access builds for features in development,
>     and eventually make it possible for the OpenJDK Community itself to
>     publish authoritative builds of the JDK.
>
> So ... that's a lot of proposed change, and there are (obviously!) many
> details to work out.  Comments?  Questions?
>
> - Mark
>
>
> [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
> [2] http://openjdk.java.net/projects/jdk9/rdp-1
> [3] http://openjdk.java.net/projects/jdk9/rdp-2
> [4] http://openjdk.java.net/projects/jdk9/rc
> [5] http://openjdk.java.net/jeps/0
> [6] http://openjdk.java.net/legal/gplv2+ce.html
> [7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html
> [8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
> [9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Andrew Hughes-8
In reply to this post by mark.reinhold
On 6 September 2017 at 15:49,  <[hidden email]> wrote:

> Over on my blog today I've argued that Java needs to move forward faster.
> To achieve that I've proposed that the Java SE Platform and the JDK shift
> from the historical feature-driven release model to 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:
>
>   https://mreinhold.org/blog/forward-faster
>
> Here are some initial thoughts on how we might implement this proposal
> here in the OpenJDK Community.  Comments and questions about both the
> proposal and its implementation are welcome on this list.
>
> Rather than create a brand new "JDK $N" Release Project every six months,
> I suggest that we create a single long-running "JDK" Release Project to
> host the main-line code base and produce the feature releases.  Similarly,
> let's create a single long-running "JDK Updates" Project to produce the
> update releases, for the most recent feature release and the current
> long-term support release.
>
> Two long-running Projects will save some administrative overhead, and also
> eliminate the confusion that regularly arises when someone is a Committer
> to JDK $N but not JDK $N + 1.  (We could consider just one long-running
> Project, but two makes more sense since since the two types of releases
> will have different policies, content, schedules, and leadership.)
>
> The new JDK Project will run a bit differently than the past "JDK $N"
> Projects:
>
>   - The main development line will always be open but fixes, enhancements,
>     and features will be merged only when they're nearly finished.  The
>     main line will be Feature Complete [1] at all times.
>
>   - We'll fork the main line into a release-stabilization branch three
>     months before the GA date of the next feature release.  That branch
>     will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2
>     [3] a month later, and then enter the Release Candidate phase [4] a
>     month after that.  (Whether the branch is another repository or an
>     actual Mercurial branch is a detail we can figure out later.)

Will these branches (whatever form they take) now be public? With the current
8u project, the stage between a release being forked for stabilization and then
released is currently non-public. There are obvious issues there with security
fixes, but currently we can only pick up a release at least a month
behind because
we don't have access to it in a finished form until release.

For example, we'll not have access to 8u152 in its final form until
late October,
so I can't see us being able to release builds based on it until November at the
earliest.

Incidentally, my vote would be for separate repositories to avoid confusion.
My experience of Mercurial branches is they don't work in the same way as
in other distributed version control systems, such as git in particular.

>
>   - We'll continue to use the JEP Process [5] for new features and other
>     significant changes.  The bar to target a JEP to a specific release
>     will, however, be higher since the work must be Feature Complete in
>     order to go in.  Owners of large or risky features will be strongly
>     encouraged to split such features up into smaller and safer parts, to
>     integrate earlier in the release cycle, and to publish separate lines
>     of early-access builds prior to integration.
>
> The JDK Updates Project will run in much the same way as the past "JDK $N"
> Updates Projects, though update releases will be strictly limited to fixes
> of security issues, regressions, and bugs in newer features.

So I imagine the use case will be similar to now, where a fix is pushed to the
main line first, and then a backport requested in the updates project? I can
see that being most relevant for the long-term support release, especially
when it gets into its second and third years.

>
> Related to this proposal, we at Oracle intend to make a few changes in
> what we do:
>
>   - 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.
>
>   - Finally, for the long term we'll work with other OpenJDK contributors
>     to establish an open build-and-test infrastructure.  This will make
>     it easier to publish early-access builds for features in development,
>     and eventually make it possible for the OpenJDK Community itself to
>     publish authoritative builds of the JDK.
>

This is great news!

What about open source features that are currently bundled with the Oracle
builds, such as JavaFX?

> So ... that's a lot of proposed change, and there are (obviously!) many
> details to work out.  Comments?  Questions?

From your blog:

"the version strings of feature releases will be of the form $YEAR.$MONTH.
Thus next year’s March release will be 18.3, and the September long-term
support release will be 18.9."

How does this interact with the idea of Java 9, 10, etc? Will those be a
thing of the past or will we see versions like 9.18.3? How does update
versioning fit in with that?

Certainly a lot of food for thought.

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Mario Torre-6
In reply to this post by mark.reinhold
On Wed, Sep 6, 2017 at 4:49 PM,  <[hidden email]> wrote:

> Over on my blog today I've argued that Java needs to move forward faster.
> To achieve that I've proposed that the Java SE Platform and the JDK shift
> from the historical feature-driven release model to 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:
>
>   https://mreinhold.org/blog/forward-faster
>
> Here are some initial thoughts on how we might implement this proposal
> here in the OpenJDK Community.  Comments and questions about both the
> proposal and its implementation are welcome on this list.
>
> Rather than create a brand new "JDK $N" Release Project every six months,
> I suggest that we create a single long-running "JDK" Release Project to
> host the main-line code base and produce the feature releases.  Similarly,
> let's create a single long-running "JDK Updates" Project to produce the
> update releases, for the most recent feature release and the current
> long-term support release.
>
> Two long-running Projects will save some administrative overhead, and also
> eliminate the confusion that regularly arises when someone is a Committer
> to JDK $N but not JDK $N + 1.  (We could consider just one long-running
> Project, but two makes more sense since since the two types of releases
> will have different policies, content, schedules, and leadership.)
>
> The new JDK Project will run a bit differently than the past "JDK $N"
> Projects:
>
>   - The main development line will always be open but fixes, enhancements,
>     and features will be merged only when they're nearly finished.  The
>     main line will be Feature Complete [1] at all times.
>
>   - We'll fork the main line into a release-stabilization branch three
>     months before the GA date of the next feature release.  That branch
>     will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2
>     [3] a month later, and then enter the Release Candidate phase [4] a
>     month after that.  (Whether the branch is another repository or an
>     actual Mercurial branch is a detail we can figure out later.)
>
>   - We'll continue to use the JEP Process [5] for new features and other
>     significant changes.  The bar to target a JEP to a specific release
>     will, however, be higher since the work must be Feature Complete in
>     order to go in.  Owners of large or risky features will be strongly
>     encouraged to split such features up into smaller and safer parts, to
>     integrate earlier in the release cycle, and to publish separate lines
>     of early-access builds prior to integration.
>
> The JDK Updates Project will run in much the same way as the past "JDK $N"
> Updates Projects, though update releases will be strictly limited to fixes
> of security issues, regressions, and bugs in newer features.
>
> Related to this proposal, we at Oracle intend to make a few changes in
> what we do:
>
>   - 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.
>
>   - Finally, for the long term we'll work with other OpenJDK contributors
>     to establish an open build-and-test infrastructure.  This will make
>     it easier to publish early-access builds for features in development,
>     and eventually make it possible for the OpenJDK Community itself to
>     publish authoritative builds of the JDK.
>
> So ... that's a lot of proposed change, and there are (obviously!) many
> details to work out.  Comments?  Questions?

This is fantastic news Mark, together with the recent Security group,
I really like where this is all going, thanks to you and all the
involved people to really pushing to the openness!

I'm curious about the model and how it will practically work out, i.e
"a new feature release every six months, update releases every
quarter, and a long-term support release every three years". Does it
means that the long-term support is the equivalent of today
jdk7jdk8/jdk9 etc.. while the other will be basically just development
version in between with various degree of stability? Or is it the goal
that every version will be production ready?

Another question is about open sourcing the commercial features. Wow,
this is really awesome, kudos! Is that "limited" to the bits that are
inside the JDK or are you planning to open source mission control as a
whole too?

Btw, thanks a lot for releasing the builds and EA binaries under an
open license, this came out a few times during our talks at FOSDEM and
I'm glad you listened to this feedback.

It's exciting times waiting ahead of us.

Cheers,
Mario
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Martijn Verburg
Hi Mark,

This is really welcome news, I suspect you're going to have a very happy X
Million developers (the twitter storm is already glowing with positive
reaction)!

Like Mario I'm also curious about how the release numbering will work.  The
change to semver in Java 9 was welcome, but did require some tooling
changes.

As for the open sourcing of items like JFR and Mission Control - that's
going to be a huge boost to the ecosystem in terms of debug and performance
tuning not to mention everything else, so thank you (and to the other
Oracle folks who helped make this decision)!


Cheers,
Martijn

On 6 September 2017 at 16:39, Mario Torre <[hidden email]> wrote:

> On Wed, Sep 6, 2017 at 4:49 PM,  <[hidden email]> wrote:
> > Over on my blog today I've argued that Java needs to move forward faster.
> > To achieve that I've proposed that the Java SE Platform and the JDK shift
> > from the historical feature-driven release model to 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:
> >
> >   https://mreinhold.org/blog/forward-faster
> >
> > Here are some initial thoughts on how we might implement this proposal
> > here in the OpenJDK Community.  Comments and questions about both the
> > proposal and its implementation are welcome on this list.
> >
> > Rather than create a brand new "JDK $N" Release Project every six months,
> > I suggest that we create a single long-running "JDK" Release Project to
> > host the main-line code base and produce the feature releases.
> Similarly,
> > let's create a single long-running "JDK Updates" Project to produce the
> > update releases, for the most recent feature release and the current
> > long-term support release.
> >
> > Two long-running Projects will save some administrative overhead, and
> also
> > eliminate the confusion that regularly arises when someone is a Committer
> > to JDK $N but not JDK $N + 1.  (We could consider just one long-running
> > Project, but two makes more sense since since the two types of releases
> > will have different policies, content, schedules, and leadership.)
> >
> > The new JDK Project will run a bit differently than the past "JDK $N"
> > Projects:
> >
> >   - The main development line will always be open but fixes,
> enhancements,
> >     and features will be merged only when they're nearly finished.  The
> >     main line will be Feature Complete [1] at all times.
> >
> >   - We'll fork the main line into a release-stabilization branch three
> >     months before the GA date of the next feature release.  That branch
> >     will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2
> >     [3] a month later, and then enter the Release Candidate phase [4] a
> >     month after that.  (Whether the branch is another repository or an
> >     actual Mercurial branch is a detail we can figure out later.)
> >
> >   - We'll continue to use the JEP Process [5] for new features and other
> >     significant changes.  The bar to target a JEP to a specific release
> >     will, however, be higher since the work must be Feature Complete in
> >     order to go in.  Owners of large or risky features will be strongly
> >     encouraged to split such features up into smaller and safer parts, to
> >     integrate earlier in the release cycle, and to publish separate lines
> >     of early-access builds prior to integration.
> >
> > The JDK Updates Project will run in much the same way as the past "JDK
> $N"
> > Updates Projects, though update releases will be strictly limited to
> fixes
> > of security issues, regressions, and bugs in newer features.
> >
> > Related to this proposal, we at Oracle intend to make a few changes in
> > what we do:
> >
> >   - 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.
> >
> >   - Finally, for the long term we'll work with other OpenJDK contributors
> >     to establish an open build-and-test infrastructure.  This will make
> >     it easier to publish early-access builds for features in development,
> >     and eventually make it possible for the OpenJDK Community itself to
> >     publish authoritative builds of the JDK.
> >
> > So ... that's a lot of proposed change, and there are (obviously!) many
> > details to work out.  Comments?  Questions?
>
> This is fantastic news Mark, together with the recent Security group,
> I really like where this is all going, thanks to you and all the
> involved people to really pushing to the openness!
>
> I'm curious about the model and how it will practically work out, i.e
> "a new feature release every six months, update releases every
> quarter, and a long-term support release every three years". Does it
> means that the long-term support is the equivalent of today
> jdk7jdk8/jdk9 etc.. while the other will be basically just development
> version in between with various degree of stability? Or is it the goal
> that every version will be production ready?
>
> Another question is about open sourcing the commercial features. Wow,
> this is really awesome, kudos! Is that "limited" to the bits that are
> inside the JDK or are you planning to open source mission control as a
> whole too?
>
> Btw, thanks a lot for releasing the builds and EA binaries under an
> open license, this came out a few times during our talks at FOSDEM and
> I'm glad you listened to this feedback.
>
> It's exciting times waiting ahead of us.
>
> Cheers,
> Mario
>
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Andrew Hughes-8
In reply to this post by Mario Torre-6
On 6 September 2017 at 16:39, Mario Torre <[hidden email]> wrote:

snip...

> involved people to really pushing to the openness!
>
> I'm curious about the model and how it will practically work out, i.e
> "a new feature release every six months, update releases every
> quarter, and a long-term support release every three years". Does it
> means that the long-term support is the equivalent of today
> jdk7jdk8/jdk9 etc.. while the other will be basically just development
> version in between with various degree of stability? Or is it the goal
> that every version will be production ready?
>

My interpretation of this was that it would be something like the Firefox
model. As Mark's blog states in more detail, the idea is for all releases
to be production ready and, indeed, for the development mainline to be
more stable in general, so big features would only go in when they
are ready to go out (implying they need to be tested heavily elsewhere)

So I see it more as distros like Fedora would pick up every feature
release, while something like RHEL would use the long-term
support release. I presume update releases would be made available
for both; basically the equivalent of the current security releases
on the same cycle. So, October 2018 & January 2019 would see
just the security update for the long-term support release, 18.9, but
April 2019 would see security updates for both 18.9 and 19.3, the next
feature release after the long-term release (assuming updates stick
to Oracle's product-wide quarterly update cycle).
--
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Volker Simonis
In reply to this post by mark.reinhold
On Wed, Sep 6, 2017 at 4:49 PM,  <[hidden email]> wrote:

> Over on my blog today I've argued that Java needs to move forward faster.
> To achieve that I've proposed that the Java SE Platform and the JDK shift
> from the historical feature-driven release model to 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:
>
>   https://mreinhold.org/blog/forward-faster
>
> Here are some initial thoughts on how we might implement this proposal
> here in the OpenJDK Community.  Comments and questions about both the
> proposal and its implementation are welcome on this list.
>
> Rather than create a brand new "JDK $N" Release Project every six months,
> I suggest that we create a single long-running "JDK" Release Project to
> host the main-line code base and produce the feature releases.  Similarly,
> let's create a single long-running "JDK Updates" Project to produce the
> update releases, for the most recent feature release and the current
> long-term support release.
>
> Two long-running Projects will save some administrative overhead, and also
> eliminate the confusion that regularly arises when someone is a Committer
> to JDK $N but not JDK $N + 1.  (We could consider just one long-running
> Project, but two makes more sense since since the two types of releases
> will have different policies, content, schedules, and leadership.)
>
> The new JDK Project will run a bit differently than the past "JDK $N"
> Projects:
>
>   - The main development line will always be open but fixes, enhancements,
>     and features will be merged only when they're nearly finished.  The
>     main line will be Feature Complete [1] at all times.
>
>   - We'll fork the main line into a release-stabilization branch three
>     months before the GA date of the next feature release.  That branch
>     will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2
>     [3] a month later, and then enter the Release Candidate phase [4] a
>     month after that.  (Whether the branch is another repository or an
>     actual Mercurial branch is a detail we can figure out later.)
>

Hi Mark,

this is all very interesting and leaves a lot romm for discussions!

If I understand everything correctly, it really reminds me of a
proposal I made back in 2013 :) when we discussed the structure of the
then new jdk 9 repos [1]:

"why don't we create something like http://hg.openjdk.java.net/dev with
master, dev, client and hotspot forest beneath it. These forests could live
"forever". Any time a new release is ready, we would then clone jdk9,
jdk10, etc from dev/master. Wouldn't that be a more natural setup?"

So could you please be a little more specific about the vision you
have for the repositories of the new "JDK Release Project"?

What does "the main development line will always be open but fixes,
enhancements, and features will be merged only when they're nearly
finished" really means?

1. Merged from where? From which other code line or repository?

2. Do we have other kind of changes than "fixes, enhancements, and features" ?

3. Currently we have jdk10/jdk10, jdk10/hs and jdk10/client. At least
all fixes and enhancements (i.e. 'the daily development stuff') go
into one of these repos. In the future, lets say we'll have something
like jdk/master, jdk/hs and jdk/client. Will all fixes and
enhancements be considered "nearly finished" by default? From my point
of view, everything else wouldn't make sense for our "daily work". I
understand that bigger "features" (i.e. Jigsaw, Value Types, etc.)
would have to be developed in their own, separate repositories until
"nearly ready" and only then merged into let's say jdk/master. Is it
this what you propose?

4. Having more features being developed in their own repositories
(until they are "nearly ready") raises the question, how changes for
such features will be reviewed? Currently we only have own repos for
quite big features like a new port, Jigsaw or Value Types to name some
examples. These "big" features have always been sponsored by OpenJDK
groups with their own, special review rules and later, when they have
been integrated into the main development repos they had to be
reviewed once again under the jdk8/jdk9/hotspot review rules. If we
will have much more features being developed in parallel to the main
development line, this approach would impose a significant overhead.
What do you think?

5. What do you mean by "The main line will be Feature Complete [1] at
all times". How can a development line be "feature complete"?
Features and JEPs will always be targeted to a specific release so
from my understanding only a release-branch can be "feature complete".
We can not know beforehand what will be in the next release which will
be forked from the development line (and this not only depends on the
OpenJDK, but also on the JCP!).

>   - We'll continue to use the JEP Process [5] for new features and other
>     significant changes.  The bar to target a JEP to a specific release
>     will, however, be higher since the work must be Feature Complete in
>     order to go in.  Owners of large or risky features will be strongly
>     encouraged to split such features up into smaller and safer parts, to
>     integrate earlier in the release cycle, and to publish separate lines
>     of early-access builds prior to integration.
>

a. Targeting for a release X now means a JEP will have to be
integrated into the main development line not later than three months
before the GA date of X (i.e. before the release-stabilization branch
will be forked). That means there's always a 6-month window (between
two forks) for bringing new features into the main line right? And
during this six month, we can only integrate features into the main
line which are targeted for next release, right?

b. In other words: every feature which is integrated into the main
line in the six month period between the forks of two releases X and Y
will be targeted for Y. But again, we can't now all the features which
will go into Y after we've forked X (and it would contradict the
'train-model' if we would know). So how could the main line be feature
complete at all times?

c. For some features, such a model may be OK. But consider a "feature"
like G1. It was in hotspot for years, before it became officially
supported (i.e. "feature complete"). I don't think we can use such a
strong model of "Feature Completeness" for such kind of projects and
insist on the fact that the main development line always has to be
"feature complete". It would also be hard to split such features into
smaller parts which can still be considered features. Any thoughts on
this?

Thank you and best regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000115.html

> The JDK Updates Project will run in much the same way as the past "JDK $N"
> Updates Projects, though update releases will be strictly limited to fixes
> of security issues, regressions, and bugs in newer features.
>
> Related to this proposal, we at Oracle intend to make a few changes in
> what we do:
>
>   - 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.
>
>   - Finally, for the long term we'll work with other OpenJDK contributors
>     to establish an open build-and-test infrastructure.  This will make
>     it easier to publish early-access builds for features in development,
>     and eventually make it possible for the OpenJDK Community itself to
>     publish authoritative builds of the JDK.
>
> So ... that's a lot of proposed change, and there are (obviously!) many
> details to work out.  Comments?  Questions?
>
> - Mark
>
>
> [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
> [2] http://openjdk.java.net/projects/jdk9/rdp-1
> [3] http://openjdk.java.net/projects/jdk9/rdp-2
> [4] http://openjdk.java.net/projects/jdk9/rc
> [5] http://openjdk.java.net/jeps/0
> [6] http://openjdk.java.net/legal/gplv2+ce.html
> [7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html
> [8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
> [9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Netroby
please move to github . be more open. be more friendly. like c# .net on github . even python now opensource on github.




On Thu, Sep 7, 2017 at 1:07 AM +0800, "Volker Simonis" <[hidden email]> wrote:










On Wed, Sep 6, 2017 at 4:49 PM,   wrote:

> Over on my blog today I've argued that Java needs to move forward faster.
> To achieve that I've proposed that the Java SE Platform and the JDK shift
> from the historical feature-driven release model to 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:
>
>   https://mreinhold.org/blog/forward-faster
>
> Here are some initial thoughts on how we might implement this proposal
> here in the OpenJDK Community.  Comments and questions about both the
> proposal and its implementation are welcome on this list.
>
> Rather than create a brand new "JDK $N" Release Project every six months,
> I suggest that we create a single long-running "JDK" Release Project to
> host the main-line code base and produce the feature releases.  Similarly,
> let's create a single long-running "JDK Updates" Project to produce the
> update releases, for the most recent feature release and the current
> long-term support release.
>
> Two long-running Projects will save some administrative overhead, and also
> eliminate the confusion that regularly arises when someone is a Committer
> to JDK $N but not JDK $N + 1.  (We could consider just one long-running
> Project, but two makes more sense since since the two types of releases
> will have different policies, content, schedules, and leadership.)
>
> The new JDK Project will run a bit differently than the past "JDK $N"
> Projects:
>
>   - The main development line will always be open but fixes, enhancements,
>     and features will be merged only when they're nearly finished.  The
>     main line will be Feature Complete [1] at all times.
>
>   - We'll fork the main line into a release-stabilization branch three
>     months before the GA date of the next feature release.  That branch
>     will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2
>     [3] a month later, and then enter the Release Candidate phase [4] a
>     month after that.  (Whether the branch is another repository or an
>     actual Mercurial branch is a detail we can figure out later.)
>

Hi Mark,

this is all very interesting and leaves a lot romm for discussions!

If I understand everything correctly, it really reminds me of a
proposal I made back in 2013 :) when we discussed the structure of the
then new jdk 9 repos [1]:

"why don't we create something like http://hg.openjdk.java.net/dev with
master, dev, client and hotspot forest beneath it. These forests could live
"forever". Any time a new release is ready, we would then clone jdk9,
jdk10, etc from dev/master. Wouldn't that be a more natural setup?"

So could you please be a little more specific about the vision you
have for the repositories of the new "JDK Release Project"?

What does "the main development line will always be open but fixes,
enhancements, and features will be merged only when they're nearly
finished" really means?

1. Merged from where? From which other code line or repository?

2. Do we have other kind of changes than "fixes, enhancements, and features" ?

3. Currently we have jdk10/jdk10, jdk10/hs and jdk10/client. At least
all fixes and enhancements (i.e. 'the daily development stuff') go
into one of these repos. In the future, lets say we'll have something
like jdk/master, jdk/hs and jdk/client. Will all fixes and
enhancements be considered "nearly finished" by default? From my point
of view, everything else wouldn't make sense for our "daily work". I
understand that bigger "features" (i.e. Jigsaw, Value Types, etc.)
would have to be developed in their own, separate repositories until
"nearly ready" and only then merged into let's say jdk/master. Is it
this what you propose?

4. Having more features being developed in their own repositories
(until they are "nearly ready") raises the question, how changes for
such features will be reviewed? Currently we only have own repos for
quite big features like a new port, Jigsaw or Value Types to name some
examples. These "big" features have always been sponsored by OpenJDK
groups with their own, special review rules and later, when they have
been integrated into the main development repos they had to be
reviewed once again under the jdk8/jdk9/hotspot review rules. If we
will have much more features being developed in parallel to the main
development line, this approach would impose a significant overhead.
What do you think?

5. What do you mean by "The main line will be Feature Complete [1] at
all times". How can a development line be "feature complete"?
Features and JEPs will always be targeted to a specific release so
from my understanding only a release-branch can be "feature complete".
We can not know beforehand what will be in the next release which will
be forked from the development line (and this not only depends on the
OpenJDK, but also on the JCP!).

>   - We'll continue to use the JEP Process [5] for new features and other
>     significant changes.  The bar to target a JEP to a specific release
>     will, however, be higher since the work must be Feature Complete in
>     order to go in.  Owners of large or risky features will be strongly
>     encouraged to split such features up into smaller and safer parts, to
>     integrate earlier in the release cycle, and to publish separate lines
>     of early-access builds prior to integration.
>

a. Targeting for a release X now means a JEP will have to be
integrated into the main development line not later than three months
before the GA date of X (i.e. before the release-stabilization branch
will be forked). That means there's always a 6-month window (between
two forks) for bringing new features into the main line right? And
during this six month, we can only integrate features into the main
line which are targeted for next release, right?

b. In other words: every feature which is integrated into the main
line in the six month period between the forks of two releases X and Y
will be targeted for Y. But again, we can't now all the features which
will go into Y after we've forked X (and it would contradict the
'train-model' if we would know). So how could the main line be feature
complete at all times?

c. For some features, such a model may be OK. But consider a "feature"
like G1. It was in hotspot for years, before it became officially
supported (i.e. "feature complete"). I don't think we can use such a
strong model of "Feature Completeness" for such kind of projects and
insist on the fact that the main development line always has to be
"feature complete". It would also be hard to split such features into
smaller parts which can still be considered features. Any thoughts on
this?

Thank you and best regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000115.html

> The JDK Updates Project will run in much the same way as the past "JDK $N"
> Updates Projects, though update releases will be strictly limited to fixes
> of security issues, regressions, and bugs in newer features.
>
> Related to this proposal, we at Oracle intend to make a few changes in
> what we do:
>
>   - 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.
>
>   - Finally, for the long term we'll work with other OpenJDK contributors
>     to establish an open build-and-test infrastructure.  This will make
>     it easier to publish early-access builds for features in development,
>     and eventually make it possible for the OpenJDK Community itself to
>     publish authoritative builds of the JDK.
>
> So ... that's a lot of proposed change, and there are (obviously!) many
> details to work out.  Comments?  Questions?
>
> - Mark
>
>
> [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
> [2] http://openjdk.java.net/projects/jdk9/rdp-1
> [3] http://openjdk.java.net/projects/jdk9/rdp-2
> [4] http://openjdk.java.net/projects/jdk9/rc
> [5] http://openjdk.java.net/jeps/0
> [6] http://openjdk.java.net/legal/gplv2+ce.html
> [7] http://www.oracle.com/technetwork/java/javase/terms/products/index.html
> [8] http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
> [9] http://www.oracle.com/technetwork/java/javase/terms/license/index.html





Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

cowwoc
In reply to this post by mark.reinhold
While I like the idea of more frequent releases, I see two problems with the
proposal in its current form:

1. It takes longer than 6 months for users to expose design problems.
Consider tagging new features with @Beta annotations, allowing the breaking
of backward compatibility for another year or so, and eventually graduating
them to stability by removing the @Beta tags.

2. Every product that has used time-based version numbers has inevitably
dropped the approach (the only exception that comes to mind is MS Word).
When this happens, the version history is permanently polluted with large
version numbers. Instead of hijacking the major.minor version numbers,
consider placing this information in the build number (e.g.
9.1.5+2017-11-15)

Gili



--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-General-discussion-f67169.html
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

cowwoc
In reply to this post by Netroby
Netroby wrote
> please move to github . be more open. be more friendly. like c# .net on
> github . even python now opensource on github.

-1 for two reasons:

1) Users will file millions of low-quality bug reports. Take a look at the
Android bug tracker to see what I mean.
2) Git is harder to use than Mercurial and Github is horribly slow for
larger projects. I should know, my employer (who I will not name) uses
Github Enterprise and the experience is so frustrating it grinds the
development process to a halt. The server is sitting on a very powerful box
in AWS so I don't think this problem will be easy to resolve.

Gili



--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-General-discussion-f67169.html
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Jonathan Bluett-Duncan
In reply to this post by cowwoc
>
> 2. Every product that has used time-based version numbers has inevitably
> dropped the approach (the only exception that comes to mind is MS Word).
> When this happens, the version history is permanently polluted with large
> version numbers. Instead of hijacking the major.minor version numbers,
> consider placing this information in the build number (e.g.
> 9.1.5+2017-11-15)


Oh, really? I thought that Ubuntu and IntelliJ IDEA still follow a
time-based version scheme.

Cheers,
Jonathan

On 7 September 2017 at 20:04, cowwoc <[hidden email]> wrote:

> While I like the idea of more frequent releases, I see two problems with
> the
> proposal in its current form:
>
> 1. It takes longer than 6 months for users to expose design problems.
> Consider tagging new features with @Beta annotations, allowing the breaking
> of backward compatibility for another year or so, and eventually graduating
> them to stability by removing the @Beta tags.
>
> 2. Every product that has used time-based version numbers has inevitably
> dropped the approach (the only exception that comes to mind is MS Word).
> When this happens, the version history is permanently polluted with large
> version numbers. Instead of hijacking the major.minor version numbers,
> consider placing this information in the build number (e.g.
> 9.1.5+2017-11-15)
>
> Gili
>
>
>
> --
> Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-General-
> discussion-f67169.html
>
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Jonathan Bluett-Duncan
>
> ...Github is horribly slow for larger projects.


I wonder if you could you point me to a particular open source project on
GitHub that suffers from this problem, and explain to me what slows down
exactly? I ask as I've worked with large projects like Bazel, and the only
slow operations I personally remember having encountered are downloading
large Git histories for the first time and importing such projects into
IDEs.

Cheers,
Jonathan

On 7 September 2017 at 20:12, Jonathan Bluett-Duncan <
[hidden email]> wrote:

> 2. Every product that has used time-based version numbers has inevitably
>> dropped the approach (the only exception that comes to mind is MS Word).
>> When this happens, the version history is permanently polluted with large
>> version numbers. Instead of hijacking the major.minor version numbers,
>> consider placing this information in the build number (e.g.
>> 9.1.5+2017-11-15)
>
>
> Oh, really? I thought that Ubuntu and IntelliJ IDEA still follow a
> time-based version scheme.
>
> Cheers,
> Jonathan
>
> On 7 September 2017 at 20:04, cowwoc <[hidden email]> wrote:
>
>> While I like the idea of more frequent releases, I see two problems with
>> the
>> proposal in its current form:
>>
>> 1. It takes longer than 6 months for users to expose design problems.
>> Consider tagging new features with @Beta annotations, allowing the
>> breaking
>> of backward compatibility for another year or so, and eventually
>> graduating
>> them to stability by removing the @Beta tags.
>>
>> 2. Every product that has used time-based version numbers has inevitably
>> dropped the approach (the only exception that comes to mind is MS Word).
>> When this happens, the version history is permanently polluted with large
>> version numbers. Instead of hijacking the major.minor version numbers,
>> consider placing this information in the build number (e.g.
>> 9.1.5+2017-11-15)
>>
>> Gili
>>
>>
>>
>> --
>> Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-General-discussion
>> -f67169.html
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

cowwoc
In reply to this post by Jonathan Bluett-Duncan
On 2017-09-07 3:12 PM, Jonathan Bluett-Duncan wrote:

>
>     2. Every product that has used time-based version numbers has
>     inevitably
>     dropped the approach (the only exception that comes to mind is MS
>     Word).
>     When this happens, the version history is permanently polluted
>     with large
>     version numbers. Instead of hijacking the major.minor version numbers,
>     consider placing this information in the build number (e.g.
>     9.1.5+2017-11-15)
>
>
> Oh, really? I thought that Ubuntu and IntelliJ IDEA still follow a
> time-based version scheme.

That's true. But these projects are in the minority. The JDK has changed
versioning schemes more often than most projects. I have nothing against
a time-based scheme in its own right, but it is extremely annoying to
step away from and I am not willing to bet that the JDK will retain this
versioning scheme for the rest of time.

Gili
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

cowwoc
In reply to this post by Jonathan Bluett-Duncan
On 2017-09-07 3:19 PM, Jonathan Bluett-Duncan wrote:
>
>     ...Github is horribly slow for larger projects.
>
>
> I wonder if you could you point me to a particular open source project
> on GitHub that suffers from this problem, and explain to me what slows
> down exactly?

I've never encounted this problem on github.com, only Github Enterprise.
I've only ever dealt with smaller projects on github.com and it's
possible that the former is better managed than Github Enterprise
installations tend to be. In the case of my particular employer, most
operations were decently fast, but opening, comments, and merging PRs
was extremely slow. This has only gotten slower over time with newer
versions of Github Enterprise and as the size of our projects have grown.

I think we're more likely to see bugs.openjdk.java.net opened to the
public before we'll see the code on Github/Bitbucket. The source-code is
already open to the public. The main benefit of moving it to
Github/Bitbucket would be to provide 2-way communication in the form of
bug reports and PRs. Given Oracle's business model, I don't see that
happening any time soon.

Gili
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

John Rose-3
In reply to this post by Jonathan Bluett-Duncan
On Sep 7, 2017, at 12:19 PM, Jonathan Bluett-Duncan <[hidden email]> wrote:
>
> large projects like Bazel

There are many degrees of large.  (About 42 in the known universe not counting Planck scale.)

Bazel looks like it has a very respectable 12k commits, 8k files, 160Mb of code, 250 authors.

The Amber repo (to take just one OpenJDK repo at random) has 45k commits, 57k files, 560Mb of code, 450 authors.

Bazel has 6 repos (including the one I quoted above).  OpenJDK has hundreds (including Amber's 8).

Whatever we do has to robustly serve a lot of code and history, for a long time.

(I'm not going to try to evaluate git[hub] vs mercurial on the merits of popularity, tools, APIs, etc.)

β€” John
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Kelly O'Hair-2
In reply to this post by cowwoc
Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry.

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

Re: Accelerating the JDK release cadence

Mario Torre-5
2017-09-07 22:30 GMT+02:00 Kelly O'Hair <[hidden email]>:
> Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry.
>
> -kto

Mercurial was a mistake all along, we should have stick to TeamWare!

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

Re: Accelerating the JDK release cadence

Kelly O'Hair-2
😏

Sent from my iPhone

> On Sep 7, 2017, at 13:58, Mario Torre <[hidden email]> wrote:
>
> 2017-09-07 22:30 GMT+02:00 Kelly O'Hair <[hidden email]>:
>> Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry.
>>
>> -kto
>
> Mercurial was a mistake all along, we should have stick to TeamWare!
>
> 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/
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Netroby
Linus hosting it's kernel repo on github. Microsoft now hosting .net
opensource on github either, python move from mercurial to github .
PHP move from svn to github, Ruby on github, Swift move to github,
Golang move to github.
Rust lang on github, Scala on github, haskell GHC on github, Clojure
on github, kotlin on github.
So why you afraid move to github?


Appreciate your time.
----------------------------
Netroby


2017-09-08 10:15 GMT+08:00 O'Hair Kelly <[hidden email]>:

> 😏
>
> Sent from my iPhone
>
>> On Sep 7, 2017, at 13:58, Mario Torre <[hidden email]> wrote:
>>
>> 2017-09-07 22:30 GMT+02:00 Kelly O'Hair <[hidden email]>:
>>> Convert from Mercurial to GIT? What a logistical nightmare. Seems like there might be bigger fish to fry.
>>>
>>> -kto
>>
>> Mercurial was a mistake all along, we should have stick to TeamWare!
>>
>> 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/
Reply | Threaded
Open this post in threaded view
|

Re: Accelerating the JDK release cadence

Alan Bateman
In reply to this post by cowwoc
On 07/09/2017 20:04, cowwoc wrote:
> While I like the idea of more frequent releases, I see two problems with the
> proposal in its current form:
>
> 1. It takes longer than 6 months for users to expose design problems.
> Consider tagging new features with @Beta annotations, allowing the breaking
> of backward compatibility for another year or so, and eventually graduating
> them to stability by removing the @Beta tags.
>
There is already support for incubating modules [1], also
-XX:+UnlockExperimentalVMOptions to enable experimental options in the
VM, and a few other mechanisms. In addition, if open build+test
infrastructure can be established then it will should make it a lot
easier for projects here to publish EA builds and should get more
feedback around a feature while it is in development rather years after
it has shipped.

-Alan

[1] http://openjdk.java.net/jeps/11
123