JavaFX 27 is now in Rampdown Phase One (RDP1) [1]. We have forked a new
jfx27 branch [2] for stabilizing the JavaFX 27 release.
Here is the short summary of what this means:
- The master branch of the jfx repo is available for integrating bug
fixes or enhancements for jfx28 . Almost all fixes will be integrated to
master for 28 , even those intended to be fixed in 27.
- The jfx27 branch of the jfx repo is now open for integrating fixes for
jfx27 that meet the RDP1 criteria as outlined below. As with the
previous release, in this release we will integrate almost all
stabilization changes via backports from the master branch [3].
* Almost all fixes intended for the jfx27 stabilization branch will
also be applicable to the master branch. Integrate such a change into
the master branch first. Then, after you have obtained any required
approvals, backport it to the stabilization branch using the Skara
`/backport` command or, if necessary, by manually opening a backport PR
with the title `Backport $HASH`, where `$HASH` is the original commit
hash. (The JDK Developers’ Guide contains more information on working
with backports [4].)
* Some fixes will be specific to the stabilization branch and not
applicable to the master branch. Integrate such a change directly into
the stabilization branch.
- Reviewers and Committers now have an additional responsibility to
verify the target branch of each pull request.
DETAILS:
P1-P3 bug fixes, and test or doc fixes of any priority are good
candidates for integrating to jfx27 during RDP1. The only hard
restriction is that enhancements need explicit approval, over and above
the review of the PR, to go into jfx27. The bar for such approval is
appropriately high. We also need to be careful to avoid potentially
risky fixes during this time. Note that these restrictions apply to the
jfx27 branch. The master branch is open for all jfx28 fixes, including
enhancements.
As a reminder, we use a single openjdk/jfx GitHub repo with
stabilization branches [5] rather than a separate stabilization repo.
The jfx27 branch is used to stabilize the upcoming jfx27 release. Please
be aware of this, especially if you are a Reviewer or Committer in the
Project. This allows all pull requests to be in the same place, but care
needs to be taken for any PR that is targeted to jfx27 to ensure that it
doesn't contain any commits from master after the jfx27 fork date. What
that means is that if you intend a PR to be for jfx27, don't merge
master into your local source branch!
IMPORTANT: Reviewers and Committers now have an extra responsibility to
double-check the target branch of each PR that they review, integrate,
or sponsor. By default a PR will be targeted to `master` which is the
main development line (JavaFX 28 as of today). This is usually what we
want. A backport PR should be targeted to `jfx27` if, and only if, it is
intended for JavaFX 27 and meets the criteria for the current rampdown
phase (we're in RDP1 as of today). Reviewers are advised to be extra
cautious in approving potentially risky fixes targeted to `jfx27`. If
there is a concern, then a reviewer can as part of the review indicate
that the PR should be retargeted to `master` for 28 . Reviewers also
need to be extra careful when reviewing PRs targeted to jfx27 that it
doesn't mistakenly contain any commits from the master branch. You'll be
able to tell because the diffs will contain changes that are not part of
the fix being reviewed. Such a PR will either need to be closed and
redone, or it will need to be rebased and force-pushed. This should be
less of a problem for this release, since almost all PRs for jfx27 will
be done as backport-style PRs, but it can still be a problem if the
developer mistakenly merges master into their backport branch.
We will use the same rules for RDP1 that the JDK uses [6], with the same
three modifications we did for the previous release:
1. Approval is needed from one of the OpenJFX project leads (not the
OpenJDK project lead)
2. Since we are not part of the JDK, we need to use labels that do not
collide with the JDK 27 release. As an obvious choice, derived from the
JBS fix version, we will use "jfx27-enhancement-request",
"jfx27-enhancement-yes", "jfx27-enhancement-no" and
"jfx27-enhancement-nmi" as corresponding labels.
3. No explicit approval (no JBS label) is needed to integrate P4 bugs to
the jfx27 branch during RDP1, as long as those bugs have otherwise met
the usual code review criteria. Having said that, most P4 bugs should
only go into master for jfx28 , since we do not want to risk anything
that would destabilize the jfx27 release without a compelling reason.
Also, we have only 3 weeks until RDP2 of jfx27 and we would be better
served fixing higher priority bugs. Note that doc bugs and test bugs of
any priority are fine to fix for jfx27 during this time.
Let me know if there are any questions.
-- Kevin
[1]
https://mail.openjdk.org/archives/list/[email protected]/thread/UCNRLDILCJTQBCJKUU7YBF7TOA3SP3FX/
[2] https://github.com/openjdk/jfx/tree/jfx27
[3] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements
[4] https://openjdk.org/guide/#working-with-backports-in-jbs
[5] https://github.com/openjdk/jfx/branches/all
[6] http://openjdk.org/jeps/3
