Skip this unless you care about update release repositories (I expect
most developer will not care).
You may have noticed that a jfx20u [1] repo was created, matching what
the JDK had already done. Prior to this release, e.g., for the 19.0.X
update releases, we were using a rather ad hoc model for non-LTS update
releases that differed from that of LTS releases. For LTS releases, we
have a separate updates repository for each code line, for example,
jdk17u [2] and jdk11u [3]. For non-LTS releases, we had previously
continued to use the feature release stabilization branch for subsequent
update releases following the GA of the feature release. That has a
couple of drawbacks. First and foremost, it means we have to remember to
ask the question "is this an LTS release or not" to know whether to use
the `jfxNN` branch in the mainline repo or the `master` branch in the
`jfxNNu` repo. The second drawback is that with the previous model,
there is no place to put fixes for the .0.1 update release until the
feature release ships.
In order to unify the procedures for LTS and non-LTS releases, I plan to
always create a `jfxNNu` repo for each release. The natural time to
create this would be some time during RDP1 of the feature release (a
week or two after the `jfxNN` branch is forked in the main repo). By
this measure, the jfx20u repo is already several weeks late in being
created, but it's still a little earlier than the jfx20 branch would
have been available for 20.0.1 fixes.
This will not impact anything related to stabilization of feature
releases, which will continue to use stabilization branches, such as
jfx20, in the main jfx repo.
NOTE: Since this is the first such release after transitioning to the
new repo model, and because we are already very late in the cycle for
the April CPU, we do not plan to accept unsolicited backport PRs to
jfx20u for 20.0.1.
-- Kevin
[1] https://github.com/openjdk/jfx20u
[2] https://github.com/openjdk/jfx17u
[3] https://github.com/openjdk/jfx11u
