Magento 2: Come specificare le dipendenze del "Versioning semantico" in composer.json del mio modulo

Lo sviluppo e la distribuzione di Magento 2 include un processo formale per il controllo delle versioni , in cui le versioni principali e secondarie dei moduli Magento principali verranno incrementate in base alle modifiche delle funzionalità compatibili con le versioni precedenti.

Come dovrei, come sviluppatore del modulo Magento, creare un elenco di requisiti nel mio file composer.json? Devo guardare manualmente il mio modulo ogni volta che utilizzo un pezzo di codice Magento di base e aggiungo una require:...riga a composer.json? O c'è uno strumento automatizzato che può farlo per me?

Come posso specificare una versione da includere nel mio composer.json? Dovrebbe essere la versione del modulo specifico che ho sviluppato contro? O dovrei essere coinvolto in una sorta di jolly? O devo prendere una decisione sulla base di compromessi? In tal caso, quali sono i compromessi coinvolti per ogni stile di versione che specifica?

Ci sono molte descrizioni di alto livello di questa funzionalità che fluttuano là fuori - ma non è molto chiaro quali passi pratici uno sviluppatore funzionante dovrebbe prendere qui e / o quali siano le conseguenze effettive di quei passi.

Devo guardare manualmente il mio modulo ogni volta che uso un pezzo di codice Magento di base e aggiungere un requisito: ... linea a composer.json?

Sì, ogni volta che nel tuo codice utilizzi qualcosa di un modulo principale, devi aggiungerlo alle esigenze del tuo compositore. Come probabilmente vorresti che il tuo ordine di caricamento fosse dopo il modulo principale, suggerirei anche di aggiungerlo al tuo module.xmlfile nella sezione sequenza.

O c'è uno strumento automatizzato che può farlo per me?

Non mi sono ancora imbattuto. Se c'è per favore fammi sapere. Dovrebbe essere uno strumento abbastanza sofisticato e richiederebbe una sostanziale copertura dei test e quindi esegue una matrice di versioni diverse per produrre un set funzionante.

Come posso specificare una versione da includere nel mio composer.json? Dovrebbe essere la versione del modulo specifico che ho sviluppato contro? O dovrei essere coinvolto in una sorta di jolly? O devo prendere una decisione sulla base di compromessi? In tal caso, quali sono i compromessi coinvolti per ogni stile di versione che specifica?

Opzioni per definire un numero di versione

1. 100.0.2
   Funziona solo quando questa versione specifica

2. 100.0.*
*è un jolly e può essere sostituito con qualsiasi numero di versione 100.0.0, 100.0.1, ...,100.0.120

3. ~100.0.2
   Rende 2 un jolly che può solo salire così 100.0.2, 100.0.3, ...,100.0.120

4. ^100.0.2
   Consente Qualsiasi rilascio entro 101 così 100.0.2, 100.0.3, ..., 100.1.0,100.2.5

Per le opzioni 2-4 se le impostazioni di stabilità lo consentono, includerebbe anche versioni simili 100.0.1-beta

Uso pratico

L'opzione 1.) è la più cauta, sai quale versione hai sviluppato e accetti di lavorare solo con questa particolare versione - il tuo modulo può essere installato solo a quel particolare modulo in quella versione. Tutti gli altri tentativi di installazione / aggiornamento falliranno con un messaggio del compositore che evidenzia che non è possibile trovare un set di componenti installabile.

Opzione 2.) Penso che possa essere considerata come non-opzione come coperta dall'opzione 3.) se la usi in questo modo ~100.0.0

Opzione 3.) Essere compatibile finché non vengono introdotte nuove funzionalità

Opzione 4.) Essere compatibile finché non vengono introdotte modifiche di rottura

Trade Offs

1 La tua estensione funziona solo per 1 versione di un modulo Magento (tecnicamente se non ci sono cambiamenti in un modulo il numero di versione non dovrebbe aumentare e più versioni di Magento Project potrebbero teoricamente includere lo stesso modulo principale Magento con la stessa versione. Praticamente I non l'ho visto e sembra che richieda alcune modifiche al processo sul lato Magento, vedi qui). Dato che sei così strettamente legato a 1 versione del modulo principale di Magento, finirai con molte versioni e versioni della tua stessa estensione, se vuoi rimanere compatibile.

3-4 L'estensione funziona con più versioni di Magento e non è necessario rilasciare versioni diverse dell'estensione ogni volta che Magento rilascia una nuova versione. Il rovescio della medaglia è che rivendichi la compatibilità anche se in Magento potrebbe essere introdotta una modifica incompatibile con il tuo codice. Questo rischio è reale in quanto la definizione di Magento di versioning semantico per le proprie versioni del modulo si estende solo a ciò che è contrassegnato da @apiun'annotazione (più su questo in questo numero GitHub ) con il suo ambito limitato.

tl; dr;
100.0.2Gioca in modo sicuro, molte versioni da mantenere per te
^100.0.2Semantic Versioning come dovrebbe funzionare, meno versioni per te ma con un rischio maggiore a causa attualmente dell'ambito limitato di @apiclassi e metodi annotati. Se avessi un'estensione che è al 100% usando classi e metodi sanzionati, questa sarebbe la scelta ovvia.

Può essere 0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,basato sulla stabilità del modulo. Come condiviso nella documentazione, il requisito sarà simile a:

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

In base al tuo aggiornamento, questo dovrebbe essere aggiornato come: -

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

Non credo ci sia ancora un sistema automatizzato per questo, ma secondo la documentazione è molto importante seguirlo.

Ma dovresti usare PATCH se ci sono correzioni di bug minori nel tuo modulo.

Fare riferimento a

PATCH indica correzioni di bug compatibili con le versioni precedenti

Hai ragione, la risposta è un po 'poco chiara, ma puoi vedere che è stata aggiornata circa 1 anno fa. Ma è così.