I would like to raise a concern about Zotero’s increasingly frequent major-version changes, particularly because the application’s major version is also being used as a plugin compatibility boundary.

The current stable release is Zotero 9, there is already a 10.0 development branch, and the `main` branch now contains `11.0.SOURCE`:

https://github.com/zotero/zotero/blob/main/version

I understand that a major version does not necessarily have to represent a complete redesign. Zotero 8 included a significant Mozilla platform upgrade and changes such as the JSM-to-ESM migration, removal of Bluebird, and changes to internal Mozilla APIs. Zotero 9 also introduced a number of new features.

However, from an ordinary user’s perspective, Zotero 8 and 9 do not feel like entirely new generations of the application. More importantly, versions 8, 9, 10, and 11 are appearing in relatively rapid succession. This would mostly be a cosmetic issue if the version number were only a product label, but it has real consequences for the plugin ecosystem.

The main problem is not the number itself. The problem is that the Zotero product version is being used as a proxy for plugin API compatibility.

Under the current model:

* A plugin may work perfectly well with a new Zotero version but still be disabled because its `strict_max_version` has not been increased.
* Plugin developers must test and update compatibility metadata for every new major version, even when no code changes are required.
* Users can upgrade Zotero and unexpectedly lose important parts of their workflow.
* The maintenance and coordination cost of frequent major releases is transferred to every plugin developer and every plugin-dependent user.
* There is no sufficiently visible pre-upgrade report showing which installed plugins will be disabled.

I understand the official reasoning that minor Zotero releases are guaranteed not to break plugins, while major releases may include UI or internal API changes. Requiring plugin developers to test a potentially breaking release is reasonable in isolation.

But this model becomes increasingly difficult to justify when major releases are frequent. It creates many cases of “administrative incompatibility”: the plugin code remains compatible, but Zotero disables it until somebody changes a version number in the manifest or update feed.

This suggests that the current compatibility model is not sufficiently granular.

Would it be possible to separate the Zotero product version from the plugin API version? For example:

```text
Zotero application version: 11.0
Stable plugin API version: 3
Mozilla platform version: 140
```

Plugins using only the stable API could declare compatibility with plugin API version 3 and remain enabled across Zotero 9, 10, and 11. Plugins using privileged internal APIs could continue to use stricter application-version limits.

A more sustainable model might include:

1. A separately versioned plugin API or ABI.
2. Capability-based compatibility declarations instead of relying mainly on the application’s major version.
3. Automatic forward compatibility for plugins that use only stable, sandboxed APIs.
4. Strict version limits only for plugins that access Zotero internals or Mozilla/XPCOM APIs.
5. A pre-upgrade compatibility check listing plugins that will be disabled.
6. Remote compatibility overrides for plugins known to work, without requiring a new XPI release.
7. A clearly announced API freeze and testing period before each compatibility-breaking release.
8. Possibly an LTS or extended-support channel for institutions and users whose workflows depend heavily on plugins.

I would also appreciate clarification on the intended meaning of a Zotero major version under the new release model:

* Does it represent a major set of user-visible features?
* A Mozilla platform upgrade?
* A potentially breaking change to internal APIs?
* Or simply a new release train?

If every release train is assigned a new major number and every major number becomes a new plugin compatibility boundary, the plugin ecosystem will face increasing maintenance costs even when the actual API changes are small.

I am not arguing that Zotero should never break internal APIs or modernize its platform. The concern is that application release numbering, internal platform changes, and plugin API compatibility are currently too tightly coupled.

Frequent releases are understandable. Frequent compatibility resets are much more disruptive.

Could the Zotero team explain whether the planned sandboxed plugin APIs will eventually allow plugins using only stable APIs to remain compatible across future major releases without repeatedly increasing `strict_max_version`?