Whoa! This is a pretty big deal. We’re talking about introducing significant changes to the public API in the middle of a point release. This breaks the intent of semver, it conflicts with the automatic version upgrading performed by the Marketplace (all plugins marked compatible with 8.5.2 will be automatically upgraded to 8.5.3, even though this won’t actually work for a bunch of plugins), and it breaks a number of implicit promises by Atlassian that the LTS releases would effectively be a refined version of the prior non-LTS release.
Can this not be deferred until the next LTS? Or just declare 8.6 as the new LTS?
I’m having trouble with 8.6 compatibility for 3 of my plugins right now and if these 8.6 struts changes are backported then I’d probably be in trouble on 8.5.x too. I don’t know which of the “… and related changes…” would end up in 8.5.x and I don’t know (yet) why I can’t get one of my xwork actions working in 8.6… I spent all day on it yesterday.
I think Scott is right (see his reply), please don’t backport breaking changes to a previous release.
Considering we first found out about this breaking change less than two months ago, forcing us to suddenly treat this as an emergency (or suffer the consequences) with zero advance notice is very much not appreciated.
We are aware of the consequences of conducting a major library upgrade as part of an LTS bugfix release.
However, in this instance we have deemed it necessary in order to ensure the highest level of security for our customers, now, and for the life of the LTS release.
introducing significant changes to the public API
The majority of API changes are covered by confluence-compat-lib:1.6.1 and thus most plugins will achieve compatibility by simply integrating it.
What is the reason behind the rush to get this breaking change backported
Any other breaking changes you may observe are also necessary for heightened product security, many of which depend on Struts 6.3.
forcing us to suddenly treat this as an emergency with zero advance notice
I apologise for not providing clarity on the timeline for these changes. Confluence 8.5.3 will still ship 3 weeks from now on its planned date of 7 Nov. We are also still evaluating whether it is viable to backport the security measures in parts.
With this in mind, our advice remains for vendors to ensure the compatibility of their plugins with Confluence 8.6.0 as soon as possible.
You wrote “delaying … many of the breaking changes until 8.5.4”. This implies that some breaking changes will be shipped in 8.5.3. Can you confirm which of the breaking changes are expected for 8.5.3 and which are expected for 8.5.4?
Also, do you have a release date estimate for 8.5.4?
Finally, are there any plans to talk with the Marketplace team to adjust the auto-update of version compatibility for Marketplace apps for when this Confluence release goes out? Point releases are not supposed to contain breaking changes, so when you release Confluence 8.5.4, all Marketplace apps currently supporting 8.5.3 will have their compatibility matrix updated to 8.5.4.
This automatic updating relies on premises that are invalid for the 8.5.x releases, because 8.5.4 will contain breaking API changes that impact multiple apps. As it stands now, as soon as 8.5.4 comes out, a number of vendors will need to log into the Marketplace to undo the automatic update and set the supported version back to 8.5.3.
As a better solution, I propose that this automatic version updating should be skipped for point releases that contain breaking API changes, such as 8.5.4.
Is it possible to publish all of the dependencies for 8.5.3? I cannot build against 8.5.3 or potentially validate these changes due to a missing JAR:
[ERROR] Failed to execute goal on project: Could not resolve dependencies for project: Could not find artifact com.atlassian.struts2:struts-support:jar:1.2.1 in atlassian-public (https://maven.atlassian.com/repository/public) -> [Help 1]