[QGIS-Developer] Plugins’ Dual QGIS 3 and QGIS 4 Compatibility

[Werner Macho]

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> 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
> >
> > @JEF partially fixed this in:
> >
> >
> 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
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260226/a8fcf1f4/attachment.htm>