I’m currently working on a set of improvements on wiki macros, which will be merged as part of the roadmap for 17.3.0RC1, and I’d like to also backport them in LTS (16.10.x branch).
To be a bit more specific, I’m working right now on having more consistency on the properties we can set on a macro, JIRA issues are:
My point of view is that it improves usability of wiki macros and it will allow to also backport in the future further improvments in existing macros. Also I estimate that the changes are not really dangerous for LTS.
So do you agree to backport those changes for the consistency of wiki macros?
Even if the new code improves usability we need to be careful to not cause regressions to existing macros (as it’s a LTS). When you say I estimate that the changes are not really dangerous for LTS. what changes do you have in mind? For example, will the changes cause the parameter order to be suddenly different when editing macros? I would expect that the parameter order are going to be different only when you specify an order, is that so?
I’d suggest to test this for a few week(s) on master first before backporting to leave time to verify it all works fine. WDYT?
Globally I’m -0 (don’t want to block it) to bring relatively important changes like this on a LTS (if it’s needed for some installed instances, it could be managed with a patch or special branch for example, but I understand the extra effort).
From what I understand, the four Jira issues surli mentionned are all about adding features to the macros, they don’t impact in any way existing macros. These new tools can impact the order once used by devs, but AFAIU these tickets don’t impact the default order of standard or custom macros (at best they give tools so that macro devs can implement an order a bit more easily). I can’t find back the ticket about updating the parameter order logic, but it’s not in here and I agree that this one would probably be too much to backport.
I like the idea Do we have this practice documented? It could be good to do this systematically for bugfixes that must be backported but require a lot of changes and can potentially break a lot of stuff in areas without automatic tests.
+1 from me for those tickets. I think backporting the the future further improvments in existing macros will need to be discussed separately later
The improvments I linked here are not at all related to the order of macro parameters. It’s only about having consistency when creating a wiki macro and a java macro so there won’t be any impact on existing macros.
We could, sure, and I’m not against it, but for this one I’m not sure it really worth it: as said I consider that those have no impact on what already exists.
Do we have this practice documented? It could be good to do this systematically for bugfixes that must be backported but require a lot of changes and can potentially break a lot of stuff in areas without automatic tests.