All OS-compatible version updates will be automatic going forward, and we won't be supporting older versions. Part of the point of rapid release is to try to ensure that everyone is on a recent version, not an old version that we can't fix problems for and that will break as soon as we make data-model changes (new fields and other long-awaited features), so providing more reasons for people not to upgrade is not the goal here.

We know that strict_max_version is tricky with rapid release, and we'll have guidance for plugin developers soon on the dev list. But Zotero 8 has been in beta for a year, so if plugins haven't been marked as compatible, it's probably not a plugin people should be relying on.

I don't want to get too far afield discussing plugins here. Zotero 8 wasn't a rapid release and required more substantial plugin changes. Faster future releases will by definition be smaller.

But I'll just say that the goal is to make it easier for plugins to stay up to date, not to integrate every useful plugin feature into Zotero.

Z6 → Z7 was a massive architectural change — across 55 "major" Firefox versions, including a complete redesign of the extensions system and a modernization of the codebase — that required all plugins to be rewritten. Z7 → Z8 was a fairly big change as well, but it required much more straightforward changes. Future releases will involve many fewer changes at once for plugin developers — that's part of the benefit of rapid releases. We're also adding new APIs for common plugin integration points, and those should generally stay stable across many versions. So it should be relatively easy for plugins updated to Z8 to stay up to date going forward.

Ultimately, though, plugin developers do need to maintain their plugins. There have been plugins that have caused major data-loss bugs or UI breakage after Zotero updates. New stable APIs will help avoid those things, and we may end up with two classes of plugins with different maintenance requirements. But regardless, we do need to know that developers both are testing with new versions and will respond quickly to any problems. If they can't commit to that, they shouldn't ask people to run their code. Given the vibrancy of the Zotero plugin ecosystem, it shouldn't be hard to find a better-maintained solution.

Glad to read this.

As much as I like Zotero and respect the work that is going into it, I think

"All OS-compatible version updates will be automatic going forward, and we won't be supporting older versions."

might be very problematic for users. If there are auto-updates to major versions with changes that make plugins unusable, this could mean that users facing e.g. a paper deadline will find Zotero unusable for their workflow in the middle of a crunch.
Such an experience will either lead to a user abandoning Zotero as soon as possible (and most likely never coming back) or to users finding creative ways to prevent updates and then not update at all.

I strongly suggest that you consider the effects of auto-updates for users.
If for example BetterBibTex is frequently not available due to auto-updates, I'm going back to JabRef. All the nice features of Zotero are useless if I find myself suddenly unable to export a bib file without lots of manual work. There are many other plugins other users might consider essential.

I understand that complaints about bugs in old versions are annoying, but forced auto-updates are not a solution to that, unless you can guarantee that you don't break the user's workflow.

Will the documentation be updated a bit more frequently as well then? sorry if that question is a bit blunt, but I saw multiple people mention the (at times very) outdated documentation and there was never an answer to it...

@iagogv: We don't have plans to do that, no.

A Zotero ESR doesn't really make sense as a concept. Firefox ESRs exist primarily to make sure organizations can still get security updates even if they don't want to deal with regular major changes. They don't get general bug fixes beyond high-impact stability fixes. But most Firefox security issues don't apply to Zotero (though we try to stay up to date with Firefox ESR updates just in case), so a Zotero ESR that only received upstream security updates would just accumulate known bugs. That's exactly what happened on our "stable" releases for years and part of what we're trying to fix here.

An ESR that also received backported bug fixes would become increasingly risky over time, since the code base would have diverged further from the current development branch without any public testing of the integrated fixes. (The beta is built from the main development branch, which is always for the next major version, so backports to the current version can't be publicly tested — that's why they need to be limited to low-risk/high-impact fixes, and why we limit the backport window to no more than a few months.)

Mozilla still puts out an ESR point release roughly every four weeks, so even Firefox's model doesn't actually let organizations go months without updating.

And Firefox's is only one model. Chrome's "Extended Stable" channel for enterprises just has major releases every 8 weeks instead of every 4 weeks, and it still has regular security updates during that time. Major versions every ~8 weeks is basically our default plan here.

If you want a version of Zotero that could be updated every couple months, that's just the current major version. We'll generally wait a week or two before pushing a major version as an auto-update (usually at x.0.1 or x.0.2), so any major issues that weren't caught during the beta should've been resolved, and there will only be noticeable changes every 6–10 weeks. Enterprises that manage updates can wait a month after a major release for 9.0.4 or so, then wait for 10.0.4, 11.0.4, etc., and just update every 6–10 weeks to an extremely well-tested version.