Comment 1 by jteh on 2011-01-19 23:01
There's no real way to do this as things stand currently. A module can import successfully but fail to run at any given point. Such is the nature of dynamic languages.

However, in future, we will have better backwards compatibility. This means that, at least for one version, deprecation warnings or similar will be issued if a module tries to use deprecated API.

We may also want to consider an NVDA version requirement or similar on app modules. If not equal to the current version, the module will fail to load.
Changes:
Changed title from "NVDA should validate user app modules against the main install binary" to "Provide a way to avoid loading incompatible app modules"
Milestone changed from None to None

@jcsteh: Do you have anything to add to your last comment?

1. Any changes relating to compatibility checks should be done for add-on packages, rather than app modules, as directly copying app modules was deprecated long ago.
2. If we change public API, we do our best to deprecate it for at least one version so authors have time to update their add-ons. We document any deprecations or removals in the What's New.
3. Users should ensure they're running the latest version of any add-ons they're using. This will be made easier once we get automatic add-on updates.
4. Add-ons can do version or API checks when installing (in installTasks), though there is no such facility when NVDA updates.
5. It has been proposed that we specify version requirements in add-on manifests. The problem with this is that when an author publishes an add-on, they can't know in what future release something they depend on might be removed.
6. Overall, I don't think there is a programmatic way to deal with this. However, I think clear documentation of deprecations and removals for developers (as we're already doing) and automatic add-on updates should sufficiently mitigate this.

Closing.