Ghidra Scripting API changes #6842
Replies: 1 comment 1 reply
-
Generally, for public interfaces, we try to deprecate changes. We also tend to keep the deprecated code around for multiple major releases, which ends up working out to be many years. We try to be especially careful with the I'm sure we sometimes make mistakes and do not correctly deprecate, but I am not aware of this happening in the |
Beta Was this translation helpful? Give feedback.
-
Ghidra's scripting interface changes slightly between versions. Sometimes finding how the scripting API has changed and documentation of what exactly changed and how is challenging. This causes some scripts to require updates from version to version, at unexpected times. For some updates this is simple refactors as was the case with Comments being moved. Other times it could be new parameters, or large changes such as the Dwarf update with Ghidra 11.
In the case of simple Ghidra refactors, Java scripting is more of an issue than Jython's as it is tough to do try-catch imports the way that python supports.
As far as I am aware the only true API/semver guarantees are around the FlatAPI. I'm wondering if more things could get pulled into FlatAPI or into services to encourage more stable APIs. I don't have good statistics or data around what has changed with sub-versions and patches, but wondering if there are thoughts around this.
Other than expanding what needs to be covered, as would be the case with expanding FlatAPI, marking things with deprecated tags for 1 major or like 2 minor releases would give some time to apply fixes. I think this would only help me if I stayed up to date and never jumped versions, so the longer the better, but knowing explicitly what is idiomatic/preferred would be awesome.
Beta Was this translation helpful? Give feedback.
All reactions