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
