Breaking Changes caused by Wizard Rewrite in 11.4

[fmagin]

I'm maintaining a plugin that used the old wizard classes from docking.wizard.*. Now when upgrading to 11.4 they have all been removed, breaking the plugin for 11.4. I can of course change all the code to use the new Wizard (which does look a lot more elegant!), but then I can't use the same codebase to support previous versions of Ghidra 11. My assumption was that something like this would only happen for major version changes, and e.g. both ways to create wizards would be available in Ghidra 11, with one of them being marked as deprecated.

• Is there any official policy for this?
• Is there some recommendation how to migrate Wizard-based UI code to Ghidra 11.4, ideally without breaking compatability with Ghidra 11.3 and before?

[dragonmacher]

We try to maintain public interfaces for long-term compatibility. I'm guessing we didn't think the wizard classes were considered part of a high-level public API.

I'm assuming your are concerned with making changes/fixes to your codebase that will still work for older Ghidra versions? We deal with this by maintaining separate branches for older release, which may then be used for minor bug fixes. I'm sure you are aware of this and I am also assuming that you are trying to avoid having to make and host multiple builds of your software that are Ghidra release dependent. But, this should work, at the expense of extra work on your part.

Perhaps a crude (but effective) solution would be to copy our old code and include it in your codebase going forward.

[fmagin]

Perhaps a crude (but effective) solution would be to copy our old code and include it in your codebase going forward.

That's exactly what I ended up doing, and that works well enough.

We try to maintain public interfaces for long-term compatibility. I'm guessing we didn't think the wizard classes were considered part of a high-level public API

It was listed in the changes under "Version Tracking", so I guess it was considered just part of that feature. It seems useful to have in general though, especially for third party plugins that interface with other services that require e.g. setting up API keys.

If you consider that a relevant enough use case, it could be argued to add these old wizards files in Ghidra 11.4.1 again, and mark them as deprecated, but maybe that use-case is too niche too warrant that.

Currently it has been sufficient to just have one code-base for that plugin which works for all public Ghidra 11 versions, and I would really like to keep it that way. In other cases it was sufficient to write the code in such a way that it supports the older Ghidra versions and the later ones were still compatible. This was the first time where I would have had to genuinely split the code. But in practice just having duplicate entries in the classpath for the wizard classes in the older versions seems fine.