[QGIS-Developer] Plugins’ Dual QGIS 3 and QGIS 4 Compatibility
Borys Jurgiel
lists at borysjurgiel.pl
Sun Mar 1 15:28:04 PST 2026
Thanks Richard and Werner for your thoughts on this. In this case it's
pretty straightforward - see https://github.com/qgis/QGIS/pull/65146
Best regards,
Borys
W dniu 26.02.2026 o 12:34, Werner Macho pisze:
> Hi Borys, all,
>
> I also made it through the mail and would prefer option 2.
> In such cases I prefer taking away the automation things and make the
> developers of the plugin responsible again.
> metadata updating should only be a matter of minutes for every plugin dev.
>
> regards
> Werner
>
> On Thu, Feb 26, 2026 at 11:40 AM Richard Duivenvoorde via QGIS-Developer
> <qgis-developer at lists.osgeo.org <mailto:qgis-developer at lists.osgeo.org>>
> wrote:
>
> Hi Borys,
>
> I fully agree with your analysis (cc'ing lova which is doing current
> plugins server software).
>
> My choice would be your option 2: dropping the Qt6 tag etc etc
>
> So what about doing this for QGIS4 only? Would that be an option?
> When we move to QGIS4/Qt6 metadata and plugins have to be updated
> anyway.
>
> Others?
>
> Regards.
>
> Richard Duivenvoorde
>
>
> On 2/24/26 21:35, Borys Jurgiel via QGIS-Developer wrote:
> > I just realized that our mess with the `qgis_maximum_version` tag
> is escalating, and this may be the last moment to rethink whether we
> really want it to be set automatically.
> >
> > Years ago, I introduced this tag to the plugin installer in order
> to extend the compatibility range to more than one major version,
> which is exactly our current case. At the same time, @ElPaso
> implemented it in the repository application, but somehow we didn’t
> fully align on the idea: for me it was optional and not meant to be
> set by default. When it is missing, the plugin installer assumes
> compatibility up to the very end of the same major version. On the
> other hand, the repository always sets it to x.99 if it is not
> present. Many authors then assumed it was mandatory and started
> tagging plugins as x.99 or x.98. I guess we never really discussed
> this topic, and now we have a full variety of `qgis_maximum_version`
> values: either explicitly set by authors or automatically added by
> the repository. Furthermore, in recent years, the `qt6_compatible`
> tag was introduced, which made perfect sense at the time. However,
> it is now redundant if at least one of the version bounds is set
> > to >= 4.0.
> >
> > Everything worked well as long as the PyQGIS API version was
> 3.99. When it was bumped to 4.0 last year (not to be confused with
> the general QGIS version), all Qt6-compatible plugins without
> `qgis_maximum_version` explicitly set to 4 became broken:
> >
> > https://github.com/qgis/QGIS/issues/62359 <https://github.com/
> qgis/QGIS/issues/62359>
> >
> > @JEF partially fixed this in:
> >
> > https://github.com/jef-n/QGIS/commit/
> eac401c009f11f58c0ac2253c98d35ec6338ca60 <https://github.com/jef-n/
> QGIS/commit/eac401c009f11f58c0ac2253c98d35ec6338ca60>
> >
> > However, this only fixed loading plugins that were already
> installed in QGIS 3. In QGIS 4, they are not available from the
> official repository, so it is impossible to (re)install them. This
> happens because the condition `if not qgisMaximumVersion (...) and
> supports_qt6`: fails twice, as the official repository always
> returns the `qgis_maximum_version` and never returns `supports_qt6`.
> >
> > This is very unexpected behaviour, so many plugin authors
> explicitly set `qgis_maximum_version` to 4.99 in their plugins, what
> is actually how the tag was originally intended to be used in the
> installer. Currently, there are 171 or 182 such plugins in the
> official repository with `qgis_maximum_version` explicitly set to >=
> 4.0 (I don't know how many Qt6-compatible plugins are in the repo in
> total).
> >
> > I can see two straightforward ways to fix this issue, but they
> raise a strategic question: do we really want `qgis_maximum_version`
> to be completed automatically?
> >
> > 1: If we want the function of forcibly bumping Qt6 plugins from
> 3.x to 4.99 to work properly, it simply needs to be implemented in
> the official repository application as well, so that such plugins
> are exposed to the installer as 4.99 rather than 3.99.
> > Pros: everything will work as expected.
> > Cons: we introduce that rather nasty hardcoded 4.99 for a couple
> of years, and anybody will understand how it works in detail.
> >
> > 2: Or should we return to the original idea: make
> `qgis_maximum_version` optional, stop adding it in the repository
> when it is not present (and only handle it internally when resolving
> the version filter), and strictly require plugin authors to set this
> tag if they want to support dual major versions? In this scenario,
> we should also drop the qt6_compatible tag.
> > Pros: we keep things simple and unambiguous.
> > Cons: we break unprepared plugins until their metadata are updated.
> >
> > Personally, I’m fine with either solution, but with this rather
> long story I just wanted to provide some context on how we ended up
> here. Thanks to anyone who made it to the end :)
> >
> > Borys
> > _______________________________________________
> > QGIS-Developer mailing list
> > QGIS-Developer at lists.osgeo.org <mailto:QGIS-
> Developer at lists.osgeo.org>
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-
> developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-
> developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org>
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>
More information about the QGIS-Developer
mailing list