About 4., it would be a nice feature if skara could automatically handle
delayed backports, e.g. could automatically remind you after some time
that the backport can now be done after it has been available in HEAD
for some time.
On 09/02/2026 14:26, Johan Vos wrote:
Hi,
TLDR: When doing a backport, it helps if you give as much information
as possible on why you believe such a backport is important.
I see an increasing number of backport requests for javafx 17, 21 and
25. It's really great to see developers wanting to improve older
versions of JavaFX.
I want to apologize for not approving all those requests, but let me
explain the reasons, and let's see how we can move forward.
First of all, integrating a backport is expensive. The resulting code
and builds are available for free, so there is a cost but no income
for this (simply said, it's sponsored by Gluon)
We run all tests on our own hardware, and we need to maintain this
hardware. Moreover, the different OS versions and build tools need to
be maintained as well, and they are often different between LTS
versions. That creates a complex situation, since we don't want to
have 3 dedicated hardware sets for 3 LTS releases. Head-releases are
relatively easy, but LTS releases require lots of
administration/infrastructure.
As most of you know, a full JavaFX build takes some time. Especially
building webkit (and especially on Windows) is a resource-intensive
process of > 1 hour. Running all tests takes even more time.
For LTS releases, it is extremely important not to break something, as
organisations rely on the assumptions that LTS releases are rock
stable. Every change, no matter how small, is a candidate for breaking
something, hence every change needs to go through rigorous
multi-platform testing.
So what backports are currently being accepted?
1. Security fixes.
This is the single most important category. When vulnerabilities are
disclosed, there needs to be a release of JavaFX LTS versions where
those vulnerabilities are addressed. That means the security fixes
that go in e.g. 26.0.1 should be backported to 17/21/25.
2. Fixes in third party components (e.g. webkit, xslt)
Security issues are often related to third party components, and in
order to apply the security fixes, it help staying on the latest release.
3. P1/P2 issues.
Clearly, we don't want to have critical bugs in the release.
4. Simple, well documented, small fixes that are already applied and
tested in HEAD and have been in a release, and that address issues
affecting a large user base and that have no dependencies on later
Java versions (e.g. JavaFX requires JDK 11, so no switch expressions etc)
Skara is extremely helpful when doing backports. If a backport can be
applied clean to an LTS repository, Skara will tell you, and the
process becomes easier. Off course, everything still needs to be tested.
When doing a backport, it helps if you give as much information as
possible on why you believe such a backport is important, and why you
think the risk is low. In case I believe the benefits of a particular
backport request do not outweigh the risk, I will reply in the PR for
that backport and we can discuss further.
- Johan
