Czy muszę ręcznie patrzeć na moduł za każdym razem, gdy używam fragmentu podstawowego kodu Magento i dodam wiersz: ... do pliku composer.json?
Tak, za każdym razem, gdy używasz w kodzie czegokolwiek z modułu podstawowego, musisz dodać go do wymagań kompozytora. Ponieważ prawdopodobnie chcesz, aby twoje ładowanie odbywało się za modułem podstawowym, sugerowałbym również dodanie go do module.xmlpliku w sekcji sekwencji.
A może istnieje zautomatyzowane narzędzie, które może to dla mnie zrobić?
Jeszcze nie spotkałem. Jeśli tak, proszę dać mi znać. Musiałoby to być dość wyrafinowane narzędzie i prawdopodobnie wymagałoby znacznego pokrycia testowego, a następnie uruchamiałoby matrycę różnych wersji w celu wytworzenia działającego zestawu.
Jak określić wersję, która ma zostać dołączona do mojego pliku composer.json? Czy powinna to być konkretna wersja modułu, przeciwko której opracowałem? A może powinienem zaangażować jakiś symbol wieloznaczny? Czy też muszę podejmować decyzję w oparciu o kompromisy? Jeśli tak, jakie są kompromisy dla każdego stylu określania wersji?
Opcje definiowania numeru wersji
100.0.2
Działa tylko wtedy, gdy ta konkretna wersja
100.0.*
*jest wieloznaczny i można zastąpić dowolnym numerem wersji
100.0.0, 100.0.1, ...,100.0.120
~100.0.2
Sprawia 2 wieloznaczny, że można tylko iść w górę tak 100.0.2, 100.0.3, ...,100.0.120
^100.0.2
Pozwala na dowolne zwolnić aż 101 tak 100.0.2, 100.0.3, ..., 100.1.0,100.2.5
W przypadku opcji 2-4, jeśli pozwalają na to ustawienia stabilności, będzie to również obejmować wersje takie jak 100.0.1-beta
Praktyczne użycie
Opcja 1.) jest najbardziej ostrożna, wiesz, dla której wersji opracowałeś i akceptujesz tylko pracę z tą konkretną wersją - moduł można zainstalować tylko obok tego konkretnego modułu w tej wersji. Wszystkie inne próby instalacji / aktualizacji zakończą się niepowodzeniem, a komunikat kompozytora podkreśli, że nie można znaleźć instalowalnego zestawu komponentów.
Opcja 2.) Myślę, że można uznać ją za taką opcję, która nie obejmuje opcji 3.), jeśli używasz jej w ten sposób ~100.0.0
Opcja 3.) Bądź kompatybilny, dopóki nie zostaną wprowadzone żadne nowe funkcje
Opcja 4.) Bądź kompatybilny, dopóki nie zostaną wprowadzone żadne przełamujące zmiany
Kompromisy
1 Twoje rozszerzenie działa tylko dla 1 wersji modułu Magento (technicznie, jeśli nie ma żadnych zmian w module, numer wersji nie powinien się zwiększać, a wiele wersji Magento Project teoretycznie może zawierać ten sam moduł główny Magento z tą samą wersją. Praktycznie I nie widziałem tego i wygląda na to, że wymaga to pewnych zmian procesu na końcu Magento (patrz tutaj). Ponieważ jesteś tak blisko związany z 1 wersją modułu podstawowego Magento, możesz uzyskać wiele wydań i wersji własnego rozszerzenia, jeśli chcesz pozostać kompatybilny.
3-4 Twoje rozszerzenie działa z wieloma wersjami Magento i nie musisz wydawać różnych wersji swojego rozszerzenia za każdym razem, gdy Magento wydaje nową wersję. Minusem jest to, że twierdzisz, że jest kompatybilny, nawet jeśli w Magento można wprowadzić zmianę niezgodną z twoim własnym kodem. To ryzyko jest realne, ponieważ definicja semantycznej wersji Magento dla własnych wydań modułowych obejmuje jedynie to, co jest oznaczone @apiadnotacją (więcej na ten temat w tym wydaniu GitHub ) o ograniczonym zakresie.
tl; dr;
100.0.2Graj bezpiecznie, wiele wydań do utrzymania dla Ciebie
^100.0.2Semantic Versioning, jak to powinno działać, mniej wydań dla ciebie, ale z większym ryzykiem ze względu na obecnie ograniczony zakres @apiadnotowanych klas i metod. Gdybyś miał rozszerzenie, które w 100% korzysta z usankcjonowanych klas i metod, byłby to oczywisty wybór.