Magento 2: Como especificar dependências de "versionamento semântico" no compositer.json do meu módulo

O desenvolvimento e implantação do Magento 2 incluem um processo formal de versionamento , em que as versões principais e secundárias dos módulos principais do Magento serão aprimoradas com base nas alterações nos recursos compatíveis com versões anteriores.

Como devo, como desenvolvedor de módulo Magento, criar uma lista de requisitos em meu próprio arquivo composer.json? Preciso olhar manualmente para o meu módulo sempre que uso um pedaço do código principal do Magento e adiciono uma require:...linha ao composer.json? Ou existe uma ferramenta automatizada que pode fazer isso por mim?

Como especifico uma versão para incluir na minha composer.json? Deve ser a versão específica do módulo contra a qual desenvolvi? Ou deveria haver algum tipo de curinga envolvido? Ou preciso tomar uma decisão com base em tradeoffs? Em caso afirmativo, quais são as compensações envolvidas para cada estilo de versão especificando?

Há muitas descrições de alto nível desse recurso flutuando por aí - mas não está claro quais etapas práticas um desenvolvedor que deve executar aqui e / ou quais são as consequências reais dessas etapas.

Preciso olhar manualmente para o meu módulo sempre que usar um pedaço do código Magento principal e adicionar uma linha de require: ... ao compositer.json?

Sim, toda vez em seu código você usa qualquer coisa de um módulo principal, é necessário adicioná-lo às necessidades do seu compositor. Como você provavelmente deseja que sua ordem de carregamento seja posterior ao módulo principal, sugiro também adicioná-lo ao seu module.xmlarquivo na seção de sequência.

Ou existe uma ferramenta automatizada que pode fazer isso por mim?

Ainda não me deparei com isso. Se houver, por favor me avise. Seria uma ferramenta bastante sofisticada e provavelmente exigiria uma cobertura de teste substancial e, em seguida, executa uma matriz de versões diferentes para produzir um conjunto de trabalho.

Como especifico uma versão para incluir no meu compositer.json? Deve ser a versão específica do módulo contra a qual desenvolvi? Ou deveria haver algum tipo de curinga envolvido? Ou preciso tomar uma decisão com base em tradeoffs? Em caso afirmativo, quais são as compensações envolvidas para cada estilo de versão especificando?

Opções para definir um número de versão

1. 100.0.2
   Funciona apenas quando esta versão específica

2. 100.0.*
*é um curinga e pode ser substituído por qualquer número da versão 100.0.0, 100.0.1, ...,100.0.120

3. ~100.0.2
   Faz 2 um curinga que só pode ir até então 100.0.2, 100.0.3, ...,100.0.120

4. ^100.0.2
   Permite que qualquer liberar até 101 modo 100.0.2, 100.0.3, ..., 100.1.0,100.2.5

Para as opções de 2 a 4, se suas configurações de estabilidade permitirem, também incluiria versões como 100.0.1-beta

Uso pratico

A opção 1.) é a mais cautelosa, você sabe em qual versão foi desenvolvida e só aceita trabalhar com essa versão específica - seu módulo pode ser instalado apenas ao lado desse módulo específico nessa versão. Todas as outras tentativas de instalação / atualização falharão com uma mensagem do compositor destacando que ele não consegue encontrar um conjunto instalável de componentes.

Opção 2.) Eu acho que pode ser pensado como não opção, como é coberto pela Opção 3.) se você usá-lo como ~100.0.0

Opção 3.) Seja compatível desde que nenhum novo recurso seja introduzido

Opção 4.) Seja compatível desde que não sejam introduzidas alterações

Trade Offs

1 Sua extensão funciona apenas para 1 versão de um módulo Magento (tecnicamente, se não houver alterações em um módulo, o número da versão não deve aumentar e várias versões do Magento Project poderiam teoricamente incluir o mesmo módulo principal do Magento com a mesma versão. não vi isso e parece que requer algumas alterações de processo no final do Magento, veja aqui). Como você está tão intimamente ligado a uma versão do módulo principal do Magento, você acaba com muitos lançamentos e versões de sua própria extensão, se quiser permanecer compatível.

3-4 Sua extensão funciona com várias versões do Magento e você não precisa lançar versões diferentes da sua extensão toda vez que o Magento lança uma nova versão. A desvantagem aqui é que você reivindica compatibilidade, mesmo que uma alteração possa ser introduzida no Magento que seja incompatível com seu próprio código. Esse risco é real, pois a definição de versão semântica do Magento para seus próprios lançamentos de módulo se estende apenas ao que está marcado com uma @apianotação (mais sobre isso nesta edição do GitHub ) com seu escopo limitado.

tl; dr;
100.0.2Jogue com segurança, muitas versões para manter para você o
^100.0.2Semantic Versioning como deve funcionar, menos versões para você, mas com maior risco devido ao escopo limitado atualmente de @apiclasses e métodos anotados. Se você tivesse uma extensão 100% usando classes e métodos sancionados, essa seria a escolha óbvia.

Pode ser 0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,baseado na estabilidade do módulo. Conforme compartilhado na documentação, o requisito será algo como: -

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

Com base na sua atualização, ela deve ser atualizada como: -

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

Eu não acho que exista algum sistema automatizado para isso ainda, mas conforme a documentação é muito importante seguir isso.

Mas você deve usar PATCH se houver pequenas correções no seu módulo.

Referir-se

PATCH indica correções de erros compatíveis com versões anteriores

Você está certo, a resposta não é clara, mas você pode ver que foi atualizada há cerca de um ano. Mas é assim que é.