Rationale for deprecating add-ons with Zotero 6?

Markus Austria
Hi!

In the discussion here

https://forums.zotero.org/discussion/95570/google-scholar-citations-for-zotero

adamsmith kindly pointed out that all that is needed for most add-ons to work under Zotero 6 is to "just updating the max version in the install.rdf file and re-zipping."

Why exactly can't there be an option in Zotero 6 (in the preferences) enabling users to simply allow add-ons with a lower max version in the install.rdf file? If this is the only adjustment needed, I am not seeing the point of blocking them in the first place.

Put differently, what's the point of deprecating add-ons that are still fully functional only because the original developers have "moved on" and will not update and re-zip them? If nothing more fundamental has changed with Zotero 6, why can't we just keep them?

This only makes Zotero *less* versatile.

Happy to discuss,
Markus
  • adamsmith
    Because version checks are a fundamental part of the Zotero add-on system and disabling them would a) not be simple and b) probably be a bad idea because add-ons *should* be tested before they're auto-updating to a major new version.
  • Markus Austria
    Yes, they *should* be tested. But even tested add-ons can go wrong (e.g., https://forums.zotero.org/discussion/95418/scite-plugin-not-working-zotero-6-0-1). This is all open-source software that comes with no warranties or liabilities, anyway.

    Why not give users the choice to "force" loading deprecated add-ons, perhaps with a warning message? It is only about allowing a lower version number, which could be fairly simple (though I have no way of knowing, of course).

    Can I file this as a feature request somewhere? I really believe this would further improve Zotero, which I really truly love and recommend to my students for years!
  • adamsmith
    This is where feature requests go; core devs read every thread, though they only respond if they have something relevant to add.
  • dstillman
    Markus: It's just part of the Mozilla add-on system that Zotero uses, and it's not adjustable at runtime, so no, we can't make it configurable.

    But as adamsmith says, compatibility checks exist for a reason.

    ZotFile, one of the most popular extensions, had a bug where running it on an attachment would wipe out any annotations created in the new PDF reader. The developer is no longer actively developing it, but because of how many people use it, we submitted a patch to fix it while bumping compatibility, and the developer pushed out a new version before Zotero 6 shipped.

    The Scite case actually proves the importance of the compatibility checks, not the opposite. The Scite plugin had a severe data corruption bug in Zotero 6, and the only reason it wasn't a complete catastrophe is that the developer is actively maintaining it, saw the reports, and pushed out a fix within hours. If the plugin were unmaintained and Zotero didn't enforce compatibility checks or there were a simple switch for users to ignore them, thousands of people would've had their data irrevocably destroyed. End users are not in a position to evaluate whether a plugin is safe to use on a major new version of Zotero.

    If the original developer has moved on, someone else should take over the development, fully test it for compatibility, and release a new, maintained version.
Sign In or Register to comment.