Magento 2: Cómo especificar dependencias de "versiones semánticas" en el compositor.json de mi módulo

El desarrollo e implementación de Magento 2 incluye un proceso formal para el control de versiones , donde las versiones principales y secundarias de los módulos principales de Magento se impulsarán en función de los cambios en las funciones compatibles con versiones anteriores.

¿Cómo debería, como desarrollador de módulos de Magento, crear una lista de requisitos en mi propio archivo composer.json? ¿Debo mirar mi módulo manualmente cada vez que uso un código de Magento central y agrego una require:...línea a composer.json? ¿O hay una herramienta automatizada que pueda hacer eso por mí?

¿Cómo especifico una versión para incluir en mi composer.json? ¿Debería ser la versión de módulo específica con la que he desarrollado? ¿O debería involucrarme algún tipo de comodín? ¿O necesito tomar una decisión basada en compensaciones? Si es así, ¿cuáles son las compensaciones involucradas para cada estilo de versión que especifica?

Hay muchas descripciones de alto nivel de esta característica flotando por ahí, pero no está muy claro qué pasos prácticos debe seguir un desarrollador en funcionamiento aquí, y / o cuáles son las consecuencias reales de esos pasos.

¿Tengo que mirar mi módulo manualmente cada vez que uso un código de Magento central y agregar un requerimiento: ... línea a composer.json?

Sí, cada vez que usa su código, desde un módulo central, debe agregarlo a las necesidades de su compositor. Como probablemente desee que su orden de carga esté después del módulo central, también sugeriría agregarlo a su module.xmlarchivo en la sección de secuencia.

¿O hay una herramienta automatizada que pueda hacer eso por mí?

Todavía no me he encontrado. Si hay, házmelo saber. Tendría que ser una herramienta bastante sofisticada y probablemente requeriría una cobertura de prueba sustancial y luego ejecuta una matriz de diferentes versiones para producir un conjunto de trabajo.

¿Cómo especifico una versión para incluir en mi composer.json? ¿Debería ser la versión de módulo específica con la que he desarrollado? ¿O debería involucrarme algún tipo de comodín? ¿O necesito tomar una decisión basada en compensaciones? Si es así, ¿cuáles son las compensaciones involucradas para cada estilo de versión que especifica?

Opciones para definir un número de versión

1. 100.0.2
   Solo funciona cuando esta versión específica

2. 100.0.*
*es un comodín y puede ser reemplazado con cualquier número de versión 100.0.0, 100.0.1, ...,100.0.120

3. ~100.0.2
   Hace 2 un comodín que sólo puede ir tan 100.0.2, 100.0.3, ...,100.0.120

4. ^100.0.2
   Permite a cualquier liberación hasta 101 por lo que 100.0.2, 100.0.3, ..., 100.1.0,100.2.5

Para las opciones 2-4 si la configuración de estabilidad lo permite, también incluiría versiones como 100.0.1-beta

Uso práctico

La opción 1.) es la más cautelosa, usted sabe con qué versión se desarrolló y solo acepta trabajar con esta versión en particular: su módulo solo se puede instalar junto con ese módulo en particular en esa versión. Todos los demás intentos de instalación / actualización fallarán con un mensaje del compositor que resalta que no puede encontrar un conjunto instalable de componentes.

Opción 2.) Creo que se puede considerar que no es una opción, como está cubierto por la Opción 3.) si la usa como ~100.0.0

Opción 3.) Sea compatible siempre que no se introduzcan nuevas funciones

Opción 4.) Sea compatible siempre que no se introduzcan cambios importantes

Compensaciones

1 Su extensión solo funciona para 1 versión de un módulo Magento (técnicamente, si no hay cambios en un módulo, el número de versión no debería aumentar y múltiples versiones del Proyecto Magento podrían incluir teóricamente el mismo módulo central de Magento con la misma versión. Prácticamente I no he visto esto y parece que requiere algunos cambios de proceso en el extremo de Magento, vea aquí). Dado que está tan estrechamente relacionado con 1 versión del módulo principal de Magento, termina con muchas versiones y versiones de su propia extensión, si desea seguir siendo compatible.

3-4 Su extensión funciona con múltiples versiones de Magento y no necesita lanzar versiones diferentes de su extensión cada vez que Magento lanza una nueva versión. La desventaja aquí es que reclamas compatibilidad aunque se pueda introducir un cambio en Magento que sea incompatible con tu propio código. Este riesgo es real ya que la definición de Magento de versiones semánticas para sus propios lanzamientos de módulos solo se extiende a lo que está marcado con una @apianotación (más sobre esto en este tema de GitHub ) con su alcance limitado.

tl; dr;
100.0.2Vaya a lo seguro, hay muchas versiones para mantener para usted
^100.0.2Versiones semánticas sobre cómo debería funcionar, menos versiones para usted, pero con un mayor riesgo debido al alcance limitado de las @apiclases y métodos anotados. Si tuviera una extensión que es 100% usando clases y métodos sancionados, esta sería la opción obvia.

Puede ser 0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,basado en la estabilidad del módulo. Como se comparte en la documentación, el requisito será algo así como:

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

Según su actualización, esto debería actualizarse como: -

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

No creo que haya ningún sistema automatizado para esto todavía, pero según la documentación es muy importante seguir esto.

Pero debe usar PATCH si hay correcciones de errores menores en su módulo.

Referirse a

PATCH indica correcciones de errores compatibles con versiones anteriores

Tiene razón, la respuesta no está clara, pero puede ver que se actualizó hace aproximadamente 1 año. Pero así es como es.