Magento 2: Festlegen von Abhängigkeiten für die semantische Versionierung in der Datei composer.json meines Moduls

Die Entwicklung und Bereitstellung von Magento 2 umfasst einen formalen Prozess für die Versionierung , bei dem Haupt- und Nebenversionen der Magento-Kernmodule aufgrund von Änderungen an abwärtskompatiblen Funktionen erweitert werden.

Wie soll ich als Magento-Modulentwickler eine Liste der Anforderungen in meiner eigenen Datei composer.json erstellen? Muss ich mein Modul jedes Mal manuell überprüfen, wenn ich einen Teil des Magento-Kerncodes verwende und eine require:...Zeile zu composer.json hinzufüge ? Oder gibt es ein automatisiertes Tool, das das für mich erledigt?

Wie gebe ich eine Version an, die in meine aufgenommen werden soll composer.json? Sollte es die spezifische Modulversion sein, gegen die ich entwickelt habe? Oder sollte es eine Art Wildcard geben? Oder muss ich eine Entscheidung treffen, die auf Kompromissen basiert? Wenn ja, welche Kompromisse ergeben sich für die einzelnen Versionsarten?

Es gibt viele allgemeine Beschreibungen dieser Funktion - aber es ist sehr unklar, welche praktischen Schritte ein arbeitender Entwickler hier unternehmen sollte und / oder welche tatsächlichen Konsequenzen diese Schritte haben.

Muss ich mein Modul jedes Mal manuell überprüfen, wenn ich einen Teil des Magento-Kerncodes verwende und der Zeile composer.json die Zeile require: ... hinzufüge?

Ja, jedes Mal, wenn Sie in Ihrem Code etwas aus einem Kernmodul verwenden, müssen Sie es den Anforderungen Ihres Komponisten hinzufügen. Da Sie wahrscheinlich möchten, dass Ihre Ladereihenfolge nach dem Kernmodul liegt, würde ich auch vorschlagen, sie Ihrer module.xmlDatei im Sequenzabschnitt hinzuzufügen .

Oder gibt es ein automatisiertes Tool, das das für mich erledigt?

Ich bin noch keinem begegnet. Wenn ja, lass es mich wissen. Es müsste ein ziemlich ausgeklügeltes Tool sein und würde wahrscheinlich eine erhebliche Testabdeckung erfordern und dann eine Matrix verschiedener Versionen ausführen, um einen Arbeitssatz zu erstellen.

Wie gebe ich eine Version an, die in meine composer.json aufgenommen werden soll? Sollte es die spezifische Modulversion sein, gegen die ich entwickelt habe? Oder sollte es eine Art Wildcard geben? Oder muss ich eine Entscheidung treffen, die auf Kompromissen basiert? Wenn ja, welche Kompromisse ergeben sich für die einzelnen Versionsarten?

Optionen zum Definieren einer Versionsnummer

1. 100.0.2
   Funktioniert nur mit dieser speziellen Version

2. 100.0.*
*ein Platzhalter ist und kann mit jeder Versionsnummer ersetzt werden 100.0.0, 100.0.1, ...,100.0.120

3. ~100.0.2
   Ergibt 2 ein Platzhalter, der nur so gehen kann 100.0.2, 100.0.3, ...,100.0.120

4. ^100.0.2
   Gestattet loslassen bis 101 so 100.0.2, 100.0.3, ..., 100.1.0,100.2.5

Für die Optionen 2 bis 4 würde es, wenn Ihre Stabilitätseinstellungen dies zulassen, auch Versionen wie enthalten 100.0.1-beta

Praktischer Nutzen

Option 1.) ist die vorsichtigste Option. Sie wissen, gegen welche Version Sie entwickelt haben, und akzeptieren nur die Arbeit mit dieser bestimmten Version. Ihr Modul kann in dieser Version nur neben diesem bestimmten Modul installiert werden. Alle anderen Installations- / Upgrade-Versuche schlagen fehl, wenn eine Composer-Meldung angezeigt wird, dass keine installierbaren Komponenten gefunden werden können.

Option 2.) Ich denke, kann als Nicht-Option betrachtet werden, wie in Option 3.) abgedeckt, wenn Sie es wie verwenden ~100.0.0

Option 3.) Seien Sie kompatibel, solange keine neuen Funktionen eingeführt werden

Option 4.) Seien Sie kompatibel, solange keine Änderungen vorgenommen werden

Kompromisse

1 Ihre Erweiterung funktioniert nur für eine Version eines Magento-Moduls (technisch gesehen sollte sich die Versionsnummer nicht erhöhen, wenn sich an einem Modul keine Änderungen ergeben, und mehrere Magento Project-Versionen könnten theoretisch dasselbe Magento-Kernmodul mit derselben Version enthalten. Praktisch I. habe dies nicht gesehen und es sieht so aus, als ob einige Prozessänderungen am Magento-Ende erforderlich sind (siehe hier). Da Sie so eng mit einer Version des Magento-Kernmoduls verbunden sind, erhalten Sie viele Releases und Versionen Ihrer eigenen Erweiterung, wenn Sie kompatibel bleiben möchten.

3-4 Ihre Erweiterung funktioniert mit mehreren Versionen von Magento und Sie müssen nicht jedes Mal, wenn Magento eine neue Version veröffentlicht, unterschiedliche Versionen Ihrer Erweiterung veröffentlichen. Der Nachteil hierbei ist, dass Sie Kompatibilität beanspruchen, obwohl in Magento eine Änderung eingeführt werden könnte, die nicht mit Ihrem eigenen Code kompatibel ist. Dieses Risiko ist real, da Magentos Definition der semantischen Versionierung für ihre eigenen Modulversionen sich nur auf das erstreckt, was mit einer @apiAnmerkung (mehr dazu in dieser GitHub-Ausgabe ) mit begrenztem Umfang gekennzeichnet ist.

tl; dr;
100.0.2Gehen Sie auf Nummer sicher, es gibt viele Releases, die Sie für
^100.0.2Semantic Versioning benötigen, weniger Releases für Sie, aber mit einem höheren Risiko aufgrund des derzeit begrenzten Umfangs an @apikommentierten Klassen und Methoden. Wenn Sie eine Erweiterung hätten, die zu 100% sanktionierte Klassen und Methoden verwendet, wäre dies die offensichtliche Wahl.

Dies kann 0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,auf der Stabilität des Moduls beruhen. Wie in der Dokumentation angegeben, lautet die Anforderung wie folgt: -

"require": {
    "myexamplestore/product-bundle": "2.0.0-RC1",
    "myexamplestore/acme-extension": "~1.0"
    }

Basierend auf Ihrem Update sollte dies wie folgt aktualisiert werden: -

"require": {
    "myexamplestore/product-bundle": "2.4.0-RC1",
    "myexamplestore/acme-extension": "~2.0"
    }

Ich glaube, es gibt noch kein automatisiertes System, aber laut Dokumentation ist es sehr wichtig, dies zu befolgen.

Sie sollten jedoch PATCH verwenden, wenn Ihr Modul kleinere Fehlerbehebungen enthält.

Beziehen auf

PATCH zeigt abwärtskompatible Fehlerkorrekturen an

Sie haben Recht, die Antwort ist etwas unklar, aber Sie können sehen, dass sie vor etwa einem Jahr aktualisiert wurde. Aber so ist es.