Seguimiento de Git en el file composer.lock

Estoy usando, como siempre compositor en mis proyectos.

Como siempre, rastreé el file composer.lock en git. Primero, porque un antiguo desarrollador principal me lo dijo. Segundo, porque realmente es práctica get todas las mismas dependencies. Y para instalarlos fácilmente en producción.

De todos modos, estoy usando alguna biblioteca en realidad. Requiere Symfony / process. El problema es que, en el server de producción, debido a la versión de PHP (5.4.44), solo puedo tener v2.8.6 de Symfony / process.

Pero en la mayoría de los desarrolladores tenemos PHP5.6 o PHP7. Entonces podríamos usar Symfony / process v3.0.6 (liberación estable de laste).

Entonces en composer.json, puse require symfony / process = 2.8.6

Entonces todos tenemos esta versión. Esto está funcionando, cualquier problema.

Todavía tengo una pregunta que me molesta todo el time. De alguna manera, me gustaría poner la versión> = 2.8.6 en composer.json, y así para dev podríamos tener v3.0.6, y en la producción la versión compatible.

Pero en este caso, tendremos un conflicto todo el time con el file composer.lock (entre desarrolladores y producción). Entonces, no podríamos seguirlo. Pero aún así, me gusta get la última versión estable. Y algunos días, actualizaremos el server de producción a PHP 5.6. Y entonces, use symfony / process a la última versión estable.

Entonces, en este tipo de caso, ¿debería dejar de seguir Composer.lock? Como podríamos get la última versión, y hacer la migration a PHP5.6 más fácil?

¿O es todavía una mejor idea para rastrear el file composer.lock?

Gracias,

Usa dos twigs, una para dev y la otra para producción o lanzamiento con su propio composer.lock. Mantenga la fusión continua de dev a la producción, a diario o cada varias horas o cualquier otro intervalo adecuado. Distribuye la producción de dev y modifica el .lock a 2.8.6. Y más tarde fusionarse de dev a producción no causará conflicto. Los desarrolladores no deben presionar desde el desarrollador local a la twig de producción remota.

Si crees que 2 twigs son inconvenientes, puedes agregar los 2 .lock a ambos en un lugar apropiado del repository. Por ejemplo, 3.xx es donde debe estar y 2.xx en otra carpeta. En el entorno de producción, puede copyr la versión 2.xx para replace la 3.xx Esto podría hacerse en algo parecido a una secuencia de commands previa a la ejecución o post-checkout .