Estrategia para aplicar un parche al código

Estamos siguiendo un patrón estándar de promoción de cambios de línea a twig para labelr una versión de producción. Cuando necesitamos parchar un cambio en la producción, los cambios se efectúan en la sucursal y se crea una nueva label desde dicha sucursal. Actualmente, es responsabilidad del autor asegurarse de que el cambio también sea llevado al tronco y probado. Desafortunadamente, en el momento de solucionar el problema de producción actual, las testings y la implementación, a veces el autor no logra llevar el cambio a la troncal y nos damos count de esto solo en la próxima regresión. Uno de mis colegas sugirió que tal vez podamos cambiar la política para que todos los cambios se prueben por primera vez en el enlace troncal y solo se puedan promocionar a la sucursal los cambios del enlace troncal.

Pros:

  • Una solución de política para evitar perderse cambios en el tronco

Contras:

  • Cuando soluciono un problema de producción, quiero probar mi solución inmediata en el código de la sucursal que se moverá a la producción, en lugar de la troncal que puede haberse movido más lejos. El time perdido al realizar cambios en una copy de avance y luego actualizar el parche para el código de sucursal parece incómodo. El contrapunto podría ser que tal vez no haya muchos escenarios en los que el tronco se mueva de forma diferente a la twig (como un cambio de paradigma).

¿Cómo se manejan tales cosas en proyectos de código abierto? También siéntase libre de señalar cualquier otro pros o mitigación de contras.