Magento 2: Jak określić zależności „Semantic Versioning” w pliku composer.json mojego modułu

Rozwój i wdrożenie Magento 2 obejmuje formalny proces wersjonowania , w którym główne i mniejsze wersje podstawowych modułów Magento zostaną zwiększone na podstawie zmian funkcji kompatybilnych wstecz.

Jak powinienem, jako programista modułu Magento, zbudować listę wymagań we własnym pliku composer.json? Czy muszę ręcznie patrzeć na moduł za każdym razem, gdy używam fragmentu podstawowego kodu Magento i dodam require:...wiersz do pliku composer.json? A może istnieje zautomatyzowane narzędzie, które może to dla mnie zrobić?

Jak określić wersję, która ma być uwzględniona w moim 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?

Istnieje wiele opisów tej funkcji na wysokim poziomie - ale nie jest jasne, jakie praktyczne kroki powinien podjąć działający programista i / lub jakie są rzeczywiste konsekwencje tych kroków.

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

1. 100.0.2
   Działa tylko wtedy, gdy ta konkretna wersja

2. 100.0.*
*jest wieloznaczny i można zastąpić dowolnym numerem wersji 100.0.0, 100.0.1, ...,100.0.120

3. ~100.0.2
   Sprawia 2 wieloznaczny, że można tylko iść w górę tak 100.0.2, 100.0.3, ...,100.0.120

4. ^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.

Może być podobny 0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,do stabilności modułu. Jak podano w dokumentacji, wymóg będzie wyglądał następująco: -

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

W zależności od aktualizacji należy ją zaktualizować w następujący sposób:

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

Nie sądzę, aby istniał jeszcze zautomatyzowany system, ale zgodnie z dokumentacją bardzo ważne jest, aby postępować zgodnie z tym.

Ale powinieneś użyć PATCH, jeśli w twoim module są drobne poprawki błędów.

Odnosić się do

PATCH wskazuje poprawki błędów zgodne z poprzednimi wersjami

Masz rację, odpowiedź jest nieco niejasna, ale widać, że została zaktualizowana około 1 roku temu. Ale tak to jest.