Die offizielle QGIS-Downloadseite führt zum Prüfstand 08.11.2026 QGIS 4.2.3 als aktuelle Version und 3.44.15 als LTR. Für ein laufendes Forschungsprojekt behalten Sie zunächst die bereits abgenommene Version; für ein neues Vorhaben testen Sie QGIS 4.2.3 getrennt, wenn eine konkrete Funktion oder Abhängigkeit dafür spricht. Planen Sie diese Woche einen Vergleich mit einer wiederherstellbaren Projektkopie. Behandeln Sie QGIS 4.4.0 nicht als verfügbare Lösung: Laut offizieller Mitteilung vom 04.11.2026 wurde die Veröffentlichung wegen Rückschritten bei der Qt5-zu-Qt6-Portierung verschoben; ein bestätigter Veröffentlichungstermin liegt nicht vor.

Dieser Leitfaden ist für Sie, wenn Sie eine laufende Abschlussarbeit oder ein langfristiges Forschungsprojekt gegen unnötige Änderungen absichern müssen.
Für ein neues Vorhaben mit Bedarf an QGIS-4.x-Funktionen finden Sie Kriterien für einen isolierten Test.
Als Administrator einer Arbeitsgruppe können Sie daraus Regeln für Versionierung, Wiederholungsprüfungen und Übergaben ableiten.

01

Versionsstatus und Auswahlrahmen

Die Wahl zwischen QGIS 4.2.3 und 3.44.15 LTR ist keine allgemeine Rangliste. Entscheidend ist, welche Version Ihre konkrete Verarbeitungskette nachweislich unterstützt. „Aktuelle Version“ bedeutet nicht automatisch „geeignete Version für ein bestehendes Projekt“. Umgekehrt ist eine LTR-Version nicht automatisch die beste Wahl für ein neu entwickeltes Werkzeug, wenn dieses ausdrücklich eine neuere Plattform oder Abhängigkeit benötigt.

Entscheidungslage Eher passende Vorgehensweise Vor der Freigabe zu klären
Laufendes Projekt mit reproduzierbaren Ergebnissen auf einer abgenommenen Version Bestehende Version beibehalten Lassen sich Projekt, Datenquellen, Modelle und Exporte auf einem zweiten System nachvollziehen?
Neues Projekt ohne festgelegte Versionsabhängigkeit Version anhand der benötigten Funktionen und Plugins auswählen Welche Version unterstützt die tatsächlich benötigten Werkzeuge?
Neues Projekt mit konkretem QGIS-4.x- oder Qt6-Bedarf QGIS 4.2.3 isoliert erproben Bestehen die Kernverarbeitung und die Ergebnisprüfung mit den verwendeten Plugins?
Migration eines laufenden Projekts mit ungeprüften Abhängigkeiten Migration aufschieben und zunächst testen Sind Projektdatei, Plugin-Verhalten und Ausgaben gegenüber der bisherigen Basis geprüft?

Die Versionsangaben und ihre Kennzeichnung als aktuelle Version beziehungsweise LTR beziehen sich auf die verlinkte offizielle Downloadseite. Prüfen Sie diese unmittelbar vor einer Installation erneut: Eine Downloadseite ist veränderlich, und eine spätere Veröffentlichung kann die Auswahlgrundlage ändern. Die Verzögerung von QGIS 4.4.0 ist ebenfalls eine Statusinformation, kein Beleg dafür, dass eine bestimmte spätere Version bereits freigegeben ist.

Ein schneller Start der Anwendung ist keine Projektabnahme. Ein Projekt kann sich öffnen und dennoch andere Ergebnisse liefern, weil ein Plugin fehlt, ein Datenpfad nicht auflösbar ist oder ein Verarbeitungsschritt abweichende Einstellungen verwendet. Deshalb sollte Ihre Entscheidung an überprüfbaren Forschungsaufgaben hängen, nicht an der Versionsnummer allein.

02

Projektkontinuität und Reproduzierbarkeit

Vor einer Änderung sollten Sie festhalten, was „funktioniert“ für Ihr Projekt bedeutet. Dazu gehören nicht nur die QGIS-Projektdatei und die sichtbare Kartenansicht. Relevant sind auch relative oder absolute Datenpfade, Koordinatenreferenzsysteme, Verarbeitungsmodelle, Layouts, Beschriftungen und exportierte Ergebnisse. Eine Projektkopie ohne die dazugehörigen Daten oder Konfigurationsinformationen ist keine brauchbare Testbasis.

Die QGIS-Dokumentation beschreibt projektbezogene Konfiguration und Einstellungen in ihrer Dokumentation zur QGIS-Konfiguration. Verwenden Sie diese als Orientierung, um projektrelevante Einstellungen von persönlichen Voreinstellungen zu unterscheiden. Halten Sie zusätzlich die externen Datenquellen und ihre Versionen fest; eine gleiche Projektdatei garantiert keine identischen Daten oder identische Verarbeitung.

Soll ein laufendes Vorhaben auf QGIS 4.2.3 wechseln?

Nur dann, wenn Sie einen nachvollziehbaren Grund für die Änderung haben und die Projektkopie die vereinbarten Prüfungen besteht. Ein Wunsch nach der neuesten Versionsnummer ist für sich genommen kein methodischer Grund. Wenn Ihre aktuelle LTR-Basis die Anforderungen erfüllt und die Abhängigkeiten nicht für die neue Version freigegeben oder geprüft wurden, ist das Beibehalten der Basis in der Regel die risikoärmere Entscheidung.

Legen Sie zunächst eine unveränderte Kopie des Projekts an. Dokumentieren Sie die QGIS-Version, die Datenquellen, die verwendeten Plugins und die wesentlichen Verarbeitungseinstellungen. Führen Sie anschließend dieselben Arbeitsschritte in der bisherigen Umgebung und in der Testumgebung aus. Vergleichen Sie nicht nur die Bildschirmdarstellung, sondern auch Tabellen, Geometrien, Koordinatenreferenzsysteme, Layouts und Exportdateien. Bei wissenschaftlich relevanten Abweichungen muss geklärt werden, ob sie aus geänderten Eingaben, Einstellungen oder Softwareabhängigkeiten stammen.

Eine praktische Prüfbasis kann so aussehen:

Prüfbereich Vergleich auf der bisherigen Basis Vergleich in der Testumgebung
Projektöffnung Projekt, Layer und Symbole vollständig? Dieselben Elemente ohne Fehlermeldung geladen?
Datenzugriff Pfade und Berechtigungen dokumentiert? Datenquellen erreichbar und korrekt zugeordnet?
Verarbeitung Parameter, Modelle und Eingaben festgehalten? Kernschritte mit denselben Parametern ausführbar?
Ergebnisse Erwartete Tabellen, Geometrien und Kennwerte gespeichert? Ergebnisse mit der festgelegten Toleranz vergleichbar?
Ausgabe Layout und Exportformat dokumentiert? Export visuell und inhaltlich geprüft?

Der Vergleich braucht keine pauschale numerische Toleranz, die für alle Forschungsfragen gelten soll. Definieren Sie die zulässige Abweichung fachlich: Für eine kartografische Darstellung kann die Layoutprüfung zentral sein, für eine räumliche Analyse dagegen die Geometrie und die Attributwerte. Wenn Ihr Fachgebiet eine bestimmte Prüfmethode verlangt, hat diese Vorrang vor einer allgemeinen Software-Checkliste.

03

Plugins und externe Abhängigkeiten

Eine Plugin-Seite kann anzeigen, dass ein Plugin installierbar ist. Das beweist nicht, dass der für Ihre Forschung benötigte Ablauf vollständig funktioniert. Trennen Sie deshalb drei Aussagen: Das Plugin lässt sich installieren; seine Kernfunktion lässt sich ausführen; der gesamte Forschungsworkflow erzeugt die erwarteten Ergebnisse. Nur die letzte Aussage kann als Abnahme des konkreten Projekts gelten.

Die QGIS-Dokumentation zur Plugin-Migration auf QGIS 4 erläutert Änderungen, die für die Anpassung von Plugins an QGIS 4 relevant sind. Nutzen Sie diese Quelle, um technische Hinweise einzuordnen, nicht als pauschale Kompatibilitätszusage für jedes Plugin. Eine allgemeine Migrationsanleitung ersetzt weder die Dokumentation des Plugin-Autors noch einen Test mit Ihren Eingaben.

Sind Plugins und Projektdateien zwischen Hauptversionen wiederverwendbar?

Das lässt sich nicht allein aus der Projektdatei beantworten. Projekte können Layer, Stile, Layouts oder Verweise enthalten, deren tatsächliche Nutzbarkeit von Datenquellen, installierten Erweiterungen und Verarbeitungsschritten abhängt. Prüfen Sie jedes für die Forschungsfrage kritische Plugin einzeln. Erfassen Sie, welche Funktion Sie verwenden, welche Version des Plugins installiert ist und ob der Anbieter eine Aussage zur Zielversion macht.

Auch externe Werkzeuge gehören in die Prüfung. Erfassen Sie insbesondere GDAL, GRASS und andere tatsächlich aufgerufene Komponenten, sofern Ihr Workflow davon abhängt. Die bloße Verfügbarkeit eines Werkzeugs im Menü belegt nicht, dass dieselben Eingaben dieselben Ergebnisse liefern. Prüfen Sie daher auch die konkreten Verarbeitungseinstellungen. Die QGIS-Anleitung zur Einrichtung des Processing-Frameworks bietet Kontext zur Verarbeitungseinrichtung; sie bestätigt nicht, dass ein bestimmtes Plugin oder Projekt mit Ihrer Datenlage funktioniert.

Führen Sie eine Abhängigkeitsliste mit diesen Angaben:

  • Name und Version jedes kritischen Plugins;
  • Zweck des Plugins im Projekt und der konkret verwendete Befehl;
  • relevante externe Programme oder Bibliotheken;
  • Quelle der Kompatibilitätsaussage: offizielle QGIS-Dokumentation, Plugin-Autor oder eigener Projekttest;
  • Ergebnis des Tests und offene Einschränkungen.

Wird eine Kompatibilität nicht ausdrücklich bestätigt, kennzeichnen Sie sie als ungeprüft. Leiten Sie keine allgemeine Aussage aus einem einzelnen erfolgreichen Start oder einem Test mit Beispieldaten ab. Für die Übergabe an Kolleginnen und Kollegen ist diese Unterscheidung wichtig: „installierbar“ und „für dieses Projekt abgenommen“ sind nicht gleichbedeutend.

04

Funktion, Werkzeugkette und macOS-Abnahme

Ein Wechsel auf QGIS 4.x sollte an einem konkreten Bedarf hängen. Beispiele sind eine benötigte Funktion, eine Entwicklungsanforderung der Arbeitsgruppe oder eine Abhängigkeit, die nur mit der neuen Werkzeugkette funktioniert. Wenn das Projekt weder eine solche Funktion noch eine entsprechende Abhängigkeit braucht, kann das Festhalten an der geprüften LTR-Basis sinnvoller sein als eine Migration ohne fachlichen Nutzen.

Für macOS müssen Sie zusätzlich den Zielrechner und die konkrete Softwareumgebung berücksichtigen. Die offizielle QGIS-Installationsanleitung für macOS ist die richtige Quelle, um die dort beschriebene Plattform- und Installationsunterstützung zu prüfen. Offizielle Unterstützung für macOS oder eine Prozessorarchitektur bestätigt jedoch nicht automatisch die Funktion eines bestimmten Plugins, eines externen Werkzeugs oder Ihres Forschungsprojekts.

Prüffeld auf macOS Was Sie verifizieren Was nicht als ausreichender Nachweis gilt
Installationsweg Entspricht der gewählte Installer der offiziellen Anleitung und dem Zielsystem? Dass sich die Anwendung einmal öffnen lässt
Prozessorarchitektur Ist die verwendete QGIS-Ausgabe für die Zielumgebung vorgesehen? Eine allgemeine Aussage über macOS-Unterstützung
Layer und Datenquellen Werden die benötigten Daten korrekt geladen und angezeigt? Eine leere Beispielkarte ohne Forschungsdaten
Verarbeitung Laufen die relevanten Modelle und Werkzeuge mit dokumentierten Parametern? Dass das Processing-Menü vorhanden ist
Layout und Export Stimmen Kartenrahmen, Beschriftung, Maßstab und exportiertes Ergebnis? Eine Prüfung nur in der Bildschirmansicht

Welche macOS-QGIS-Version passt zur Forschungsarbeit?

Für ein laufendes Projekt ist die passende Version diejenige, mit der die Forschungsarbeit bereits verlässlich ausgeführt wird und deren Abhängigkeiten dokumentiert sind. Für ein neues Projekt können Sie QGIS 4.2.3 erproben, wenn Sie dafür einen konkreten funktionalen oder technischen Bedarf nachweisen. Testen Sie auf Apple Silicon oder einer Intel-Umgebung nur mit einer Kopie des Projekts und anhand der offiziellen Installationshinweise für genau diese Zielumgebung.

Die Prüfung sollte mindestens die in Ihrem Projekt tatsächlich verwendeten Layer, Verarbeitungsschritte, Layouts und Exporte abdecken. Bei einem Projekt, das keine Plugins verwendet, ist eine Pluginprüfung nicht künstlich zu ergänzen; bei einem Projekt mit kritischem Plugin darf dieser Test dagegen nicht übersprungen werden. Halten Sie auch fest, ob Sie mit einer nativen Installation oder einer anderen unterstützten Installationsvariante gearbeitet haben. Diese Angaben helfen, einen späteren Unterschied bei der Wiederholung einzugrenzen.

05

Versionstest und Teamübergabe

Führen Sie die Versionsprüfung in einer Umgebung durch, die Ihre produktive Forschungsbasis nicht verändert. Die QGIS-Downloadseite listet die dort verfügbaren Versionen; die macOS-spezifischen Installationsschritte richten Sie nach der verlinkten Installationsanleitung. Verwenden Sie für den Test keine einzige Projektdatei als gleichzeitig veränderbare Produktions- und Versuchskopie.

  1. Ausgangsbasis sichern. Notieren Sie die derzeit freigegebene QGIS-Version, die Betriebssystemumgebung und den Speicherort der Projektkopie. Sichern Sie Projektdatei, Modelle, Stile und die für den Test erforderlichen Daten nach den Regeln Ihrer Einrichtung.
  2. Projektzustand dokumentieren. Halten Sie Koordinatenreferenzsysteme, Datenpfade, Plugin-Abhängigkeiten und Verarbeitungseinstellungen fest. Speichern Sie erwartete Zwischenergebnisse oder Exporte, sofern deren Aufbewahrung datenschutz- und lizenzrechtlich zulässig ist.
  3. Zielversion isoliert installieren. Folgen Sie der offiziellen macOS-Anleitung und vermeiden Sie Änderungen an der bestehenden Arbeitsumgebung, solange diese für ein laufendes Vorhaben benötigt wird. Prüfen Sie, dass Sie eindeutig erkennen können, welche Version den Test ausgeführt hat.
  4. Kernworkflow wiederholen. Öffnen Sie die Kopie, laden Sie die relevanten Daten und führen Sie die für die Forschungsfrage entscheidenden Verarbeitungsschritte aus. Ein kurzer Anwendungstest ohne den realen Arbeitsablauf reicht nicht.
  5. Ergebnisse vergleichen. Prüfen Sie Attribute, Geometrien, Koordinatenreferenzsysteme, Layouts und Exporte. Kennzeichnen Sie Abweichungen und bewerten Sie sie fachlich; übernehmen Sie neue Ergebnisse nicht stillschweigend in die Forschungsbasis.
  6. Abhängigkeiten einzeln abnehmen. Prüfen Sie kritische Plugins und externe Werkzeuge mit den konkreten Befehlen des Projekts. Trennen Sie dabei die Aussage des Plugin-Autors von Ihrer eigenen Projektprüfung.
  7. Entscheidung protokollieren. Halten Sie fest, ob Sie die bestehende Version beibehalten, die neue Version nur für ein neues Projekt freigeben oder eine Migration beginnen. Nennen Sie offene Tests und die Person, die vor der nächsten Freigabe entscheidet.

Für die Teamübergabe sollte das Protokoll mindestens die QGIS-Version, macOS-Zielumgebung, Installationsquelle, Plugin- und Werkzeugabhängigkeiten, Datenpfadregeln, Prüfschritte und Testergebnisse enthalten. Ergänzen Sie bekannte Grenzen, etwa ein nicht geprüftes Plugin oder einen Export, der noch nicht mit den institutionellen Vorlagen verglichen wurde. Eine Kollegin oder ein Kollege muss erkennen können, ob ein Ergebnis mit der freigegebenen Umgebung oder nur in einem Versuch erzeugt wurde.

Wie wirkt sich die Verzögerung von QGIS 4.4.0 auf die Auswahl aus?

Die Verzögerung bedeutet zunächst, dass Sie die offiziell genannte Veröffentlichung nicht als verfügbare Option einplanen sollten. Die Projektmitteilung nennt Rückschritte bei der Portierung von Qt5 zu Qt6 und bestätigt keinen Termin, der als verbindlich gelten kann. Planen Sie deshalb weder eine Migration noch eine Abgabe so, als sei QGIS 4.4.0 bereits erschienen. Prüfen Sie den Status bei Bedarf erneut anhand der offiziellen Mitteilung und der Downloadseite, bevor Sie Ihre Entscheidung ändern.

06

Entscheidung für das Forschungsprojekt

Nutzen Sie diese Regeln für die Freigabe:

  • Beibehalten: Das Projekt ist in einer bestehenden Version abgenommen, und ein fachlicher Bedarf an QGIS 4.x ist nicht belegt.
  • Isoliert testen: Ein neues Vorhaben benötigt eine konkrete Funktion oder Werkzeugkette aus QGIS 4.x; der Test verändert nicht die produktive Basis.
  • Migration zurückstellen: Ein kritisches Plugin, eine externe Abhängigkeit oder ein Ergebnisvergleich ist noch nicht geprüft oder weicht ungeklärt ab.

QGIS 4.2.3 oder 3.44.15 LTR ist damit keine Entscheidung, die sich allein aus „neu“ gegen „LTR“ ableiten lässt. Für laufende Arbeiten zählt die nachvollziehbar geprüfte Basis. Für neue Arbeiten zählt, ob der konkrete Funktionsbedarf den Test rechtfertigt und ob Ihr Projekt die Abnahme besteht.

Ein Windows- oder Linux-Rechner aus dem Labor kann für viele GIS-Aufgaben passend sein, ersetzt aber keine Prüfung des macOS-Verhaltens, wenn Ihre Forschungsumgebung genau dieses System verlangt. Ein eigener Mac verursacht Anschaffungs- und Betreuungsaufwand und ist für einen zeitlich begrenzten Kompatibilitätstest nicht immer die passende Wahl. Wenn Ihrer Arbeitsgruppe eine freigegebene macOS-Umgebung fehlt, können Sie nach Zustimmung Ihrer Einrichtung und Prüfung der Datenschutzregeln eine zeitlich begrenzte Remote-Mac-Umgebung als Testoption bewerten. Bei sensiblen Forschungsdaten gilt: erst Datenfreigabe und Übertragungsweg klären, dann testen. Für langfristige, dauerhaft hohe Auslastung oder benötigte physische Schnittstellen kann ein eigener Rechner besser passen. Informationen zu Remote-Mac-Umgebungen bei VpsMesh und den Mietpreisen helfen Ihnen, diese Option mit der vorhandenen Laborinfrastruktur zu vergleichen. Beginnen Sie mit einer nicht sensiblen Projektkopie und geben Sie keine Version für die Forschungsarbeit frei, bevor die fachlichen Ergebnisse geprüft sind.

Zuletzt aktualisiert am 08.11.2026. Versionsstatus und QGIS-4.4.0-Mitteilung wurden anhand der offiziellen Downloadseite und des offiziellen Projektblogs geprüft. macOS-Unterstützung, Konfiguration, Plugin-Migration und Processing-Hinweise beruhen auf den jeweils verlinkten QGIS-Dokumentationen.