Eine öffentliche Go-Bibliothek ändern, ohne den Code ihrer Anwender zu brechen

## Vor Codeänderungen unterstützte Go-Versionen und Zweige prüfen Behandle Korrektheit, Rückwärtskompatibilität und anwendbare externe Spezifikationen als vorrangige Abnahmekriterien. Ermittle vor jeder Codeänderung: - den aktiven Entwicklungszweig und den neuesten stabilen Wartungszweig; - die niedrigste Go-Version, die für Anwender unterstützt wird; - die neuere Go-Version und die Werkzeugkette, die für die Entwicklung des Repositoriums erforderlich sind; - welche Pakete die öffentliche, von der Kompatibilitätszusage erfasste API bilden; - welche importierbaren internen oder experimentellen Pakete außerhalb der Zusagen der semantischen Versionierung liegen, in der Praxis aber dennoch genutzt werden. Gehe nicht davon aus, dass „nicht von der semantischen Versionierung erfasst“ gleichbedeutend mit „gefahrlos inkompatibel änderbar“ ist. Kennzeichne Verhaltens- oder API-Änderungen, die tatsächliche Anwender beeinträchtigen könnten. Führe neue Funktionen gemäß der Repositoriumsrichtlinie dem Entwicklungszweig und Fehlerbehebungen dem passenden stabilen Zweig zu. Vermeide in öffentlichen Paketen Programmierschnittstellen der Standardbibliothek und Sprachmerkmale, die neuer als die angegebene niedrigste Go-Version sind. Halte die Kompatibilitätsprüfung im Build ausführbar, damit nicht unterstützte Merkmale frühzeitig fehlschlagen und nicht bis zu den Anwendern gelangen. ## Prüfungen und Tests mit den Werkzeugen des Projekts ausführen Verwende die Aufgabensteuerung und das festgelegte Formatierungswerkzeug des Projekts, statt sie durch vertraute Befehle zu ersetzen. Das vorgegebene Prüfziel soll Kompilierung, Lizenzprüfung, Formatprüfung, Modulprüfung, statische Codeprüfung und schnelle Tests gemeinsam ausführen. Pflege zwei Teststufen: - eine kurze Testsammlung mit Erkennung von Datenrennen für schnelle Rückmeldungen; - eine vollständige Integrationstestsammlung mit den erforderlichen Dienstabhängigkeiten des Repositoriums und verlängerter Zeitüberschreitung. Wenn Integrationstests gemeinsamen Serverzustand verwenden, muss die vollständige Testsammlung seriell laufen. Erhöhe die Parallelität niemals allein zur Verkürzung der Laufzeit. Dienstendpunkte sollen konfigurierbar sein; ein dokumentierter lokaler Vorgabewert muss erhalten bleiben. Führe architekturübergreifende statische Prüfungen oder Kompilierungsprüfungen aus, wenn systemnahes Verhalten von der Rechnerarchitektur abhängt. Prüfe beim Einsatz atomarer Zugriffe insbesondere 32-Bit-Ziele: Atomar angesprochene 64-Bit-Felder müssen sicher ausgerichtet sein, etwa am Anfang einer Struktur stehen oder typisierte Atomar-Hüllen verwenden. ## Fehler und öffentliche APIs nach den Mustern der Bibliothek schreiben Halte dich an die im Repositorium etablierten Muster: - Reichere Fehler beim Umschließen mit `%w` um Kontext an und vergleiche sie mit `errors.Is` oder `errors.As`, anstatt Meldungstexte abzugleichen. - Verwende `context.Context` als erstes Argument jeder blockierenden öffentlichen Methode und leite Fristen aus dem Kontext des Aufrufers ab, statt konkurrierende Zeitgeber mit eigener Echtzeitmessung einzuführen. - Nutze geordnete Dokumenttypen für Befehle oder Daten, bei denen die Schlüsselreihenfolge wichtig ist, und abbildungsartige Typen nur, wenn die Reihenfolge tatsächlich keine Rolle spielt. Verwende systemnahe, auf Bytefolgen gestützte Darstellungen ausschließlich in begründeten leistungskritischen Pfaden. - Schreibe exportierte Bezeichner aus, dokumentiere alle exportierten Bezeichner mit dem Namen als Satzgegenstand und folge bei neuen Optionen dem Erbauer- oder Setzer-Muster des Projekts. Bewahre die bestehende Paketzuordnung und getroffene Migrationsentscheidungen. Stelle außer Betrieb genommene Importpfade oder veraltete öffentliche Abstraktionen nicht wieder her. Wenn Befehlsüberwachung oder Diagnosevorgänge Authentifizierungsaustausch beobachten können, müssen Befehle mit Anmeldedaten vor der Bereitstellung der Ereignisse in die Schwärzungsrichtlinie aufgenommen werden. Funktionsspezifische native Abhängigkeiten und Build-Kennzeichnungen müssen in den Einrichtungs- und Testanweisungen ausdrücklich genannt bleiben. ## Unit- und Integrationstests trennen und die für die Änderung nötigen ausführen Lege Komponententests neben der Implementierung und Integrationstests im Integrationsbereich des Repositoriums ab. Verwende die Prüfhelfer des Projekts und bevorzuge bedeutungsbezogene Prüfungen wie `ErrorIs` gegenüber Teilzeichenkettenvergleichen. Nutze für Integrationsverhalten das vorgegebene topologiebewusste Testgerüst zur Bereitstellungseinrichtung, Einspeisung von Fehlerpunkten und Ereigniserfassung. Bewahre Spezifikations-Testdaten am vorgesehenen Ort auf, initialisiere nach dem Klonen die benötigten Untermodule oder Testdatenquellen und nummeriere beschreibende Testfälle entsprechend der maßgeblichen Spezifikation, wenn Rückverfolgbarkeit erforderlich ist. Führe vor der Prüfung durch andere das vorgegebene Prüfziel aus. Berührt eine Änderung Integrationsverhalten oder gemeinsam genutzten Serverzustand, führe die vollständige Testsammlung seriell aus. Ein bestandener enger Komponententest ist kein ausreichender Nachweis für architekturübergreifende, kompatibilitätskritische oder spezifikationsabhängige Änderungen. ## Einen Änderungsantrag mit Testergebnissen und Kompatibilitätsfolgen vorbereiten Verwende in Commit-Nachrichten und Titeln von Änderungsanträgen das vorgeschriebene Arbeitsaufgabenpräfix. Der Änderungsantrag muss das für Anwender sichtbare Verhalten, die Kompatibilitätsauswirkungen, die Testnachweise und die Wahl des Zweigs erläutern. Ergänze änderungsspezifische Nachweise: - Erzeuge bei Änderungen an öffentlichen APIs den API-Bericht des Repositoriums und füge ihn dem Änderungsantrag bei. - Aktualisiere bei für Anwender sichtbaren inkompatiblen Änderungen den zugehörigen Migrationsleitfaden. - Zitiere bei Arbeiten zur Spezifikationseinhaltung die genaue Anforderung, die von der Implementierung erfüllt wird. - Weise bei Änderungen an importierbaren experimentellen Paketen ausdrücklich auf Inkompatibilitäten hin, auch wenn die semantische Versionierung dies nicht verlangt. Stelle eine Änderung nicht allein deshalb als bereit dar, weil sie lokal kompiliert. Bereitschaft setzt die vorgegebenen Repositoriumsprüfungen sowie jede unmittelbar anwendbare Kompatibilitäts-, Integrations-, API- und Spezifikationsprüfung voraus.