...

The OpenFX 9 release is aimed at stabilization, modularization support, and some modest improvements to the platform. The scope has not yet been determinedfinalized.

Development repo: http://hg.openjdk.java.net/openjfx/9-dev/rt

Rules for pushing code to 9

For now, we still automatically As of March 30, 2015 we no longer forward-sync changes from 8u to 9 each week. This means that: A) you must avoid any significant refactoring, white space changes, etc., in 9-dev that might cause difficult-to-resolve merge conflicts; and B) any change that is intended for 8u40 should be pushed to 8u-dev only and not also to 9-dev (it will get synced into 9-dev at the next integration). We will update the Wiki and send an announcement to the openjf-dev mailing list when this changes, likely in mid-December 2014.It is now the developer's responsibility to push changes directly to 9-dev. In fact, most changes should be pushed first to 9-dev and then backported to 8u-dev (or pushed at the same time). This follows the JDK model of pushing changes to the development code line first and then backporting to prior releases as appropriate. Risky changes might wait to be baked in 9-dev for a week or two, but most simple bug fixes can be backported much sooner (if not at the same time).

We haven't finalized Until we determine the scope of the FX work for 9, the changesets should be limited to bug fixing and minor improvements; no API changes or new functionality should be added yetbut some minor improvements in addition to bug fixes might be accepted. The code review policies are the same as normal (non-milestone) weeks for 8u-dev.currently used for 8u-dev. If you are backporting a bug fix from 9-dev to 8u-dev that is substantially the same changeset – either it imports cleanly or only differs from the 9-dev patch in white-space or context -- then a separate review is not needed to push to 8u-dev. The review you did for 9-dev is enough.

API changes and other application visible behavior changes require additional approval via the API review process. Such API changes that are approved for 9 must not be backported to 8u-dev (for 8u60), since we are past feature freeze. There might be some exceptions to this policy, but they will be rare and require separate approval for the backport.

Sanity Testing / Weekly Code Freeze

Our testing is still mostly focused on 8u40, so there is no 8u60, but that will change over time. As such, we will observe the same weekly lockout period yet for 9. We plan to take a snapshot for integration at the same time as we start sanity testing -dev as for 8u-dev (: 1am - 1pm Pacific time on Monday). Stay tuned for changes on this front once 8u40 repo is forked and we go into rampdown for that release. Until then, sanity testing will be limited, so be careful to test your own changes, and will start doing at least limited testing on 9-dev. See  Sanity Testing for details.

UNDER CONSTRUCTION

The following is under construction and is not complete or fully thought out.

...