Estoy escribiendo un script que aumenta la versión del paquete en función de la diferencia en las confirmaciones entre la rama master y la rama current . Estoy usando conventional commits para decidir qué número actualizar.
Digamos que tengo 1.0.0 por defecto
BREAKING CHANGE: actualiza el mayor +1 y deja intactos otros dígitos incluso si hubo otros cambios, por lo que obtengo 2.0.0feat: actualizaciones menores +1, y obtendríamos 1.1.0fix: parche actualizado +1, y nos da 1.0.1Tengo un par de preguntas con respecto a dicho método de control de versiones:
current con la feat: o fix: ¿debería actualizar la versión menor/parche de acuerdo con el número de estas confirmaciones o debería ser solo +1? Por ejemplo, hay 3 confirmaciones con feat: en la rama current , cuando combino la rama con la master , ¿debería ser la versión 1.4.0 o solo 1.1.0 ?
fix: si ya tuviera feat: :? Por ejemplo, hay 1 feat: y 1 fix: cuando se fusiona con el master , ¿la versión debe convertirse en 1.1.1 o 1.1.0 ?
Semver hace un reinicio en dos casos:
Con el cambio más importante. Ej: 1.4.3 -> 1.5.0 -> 2.0.0.
Y cuando se suelta, se lleva la más importante. Ej: master está en 1.0.0. Tienes 5 cambios de última hora, varios menores y parches en la rama current . Solo toma en cuenta 1 cambio importante y hace 1.0.0 -> 2.0.0.
Bueno, lógicamente es la mejor manera ya que al usuario de la aplicación no le importa el proceso por el que ha pasado en el desarrollo.