¿Cuándo debo incrementar el número de versión?

23

No aprendí programación en la escuela y no trabajo como desarrollador (profesional), por lo tanto, muchos conceptos básicos no me quedan del todo claros. Esta pregunta trata de aclarar uno de ellos.

Ahora supongamos que tengo problemas #1, #2y #3en mi Rastreador de problemas que están configurados para ser corregidos / mejorados para la versión 1.0.0y que la última versión (estable) es 0.9.0.

¿Cuándo debo incrementar a la versión 1.0.0? Cuando a) solo uno de los problemas enumerados anteriormente está cerrado ob) cuando todos los problemas relacionados con la versión 1.0están cerrados.

¿Cuál es la forma correcta de hacerlo? Y por el camino correcto , me refiero a lo que se usa actualmente en la industria.

versioning semantic-versioning ahmed
fuente
22
Ver semver.org
Martijn Pieters
1
Y también puede incluir los tres problemas en su próxima versión.
Martijn Pieters
Sí, ya estoy usando SemVer y TODOS los tres problemas deben presentarse en la próxima versión :)
ahmed
Edité la pregunta para evitar confusiones.
Ahmed

Respuestas:

14

Puedo decirte cómo lo hago en el trabajo.

Tenemos un servidor de integración continua que crea, prueba, etiqueta y genera un paquete versionado. Solo procedemos a la siguiente etapa si la anterior es% 100 exitosa.

Nuestra versión se ve así: <Versión principal>. <Versión menor>. <Número de compilación>

  • Cada compilación exitosa que no haya completado la corrección de errores o la mejora de características incrementa el número de compilación.
  • Cada compilación exitosa con una corrección de errores completa o una mejora de características incrementa la versión menor. Esto se detecta automáticamente por la presencia de un mensaje de confirmación utilizando un formato particular. Este mensaje de confirmación también se incluye automáticamente en los proyectos ChangeLog.
  • Cada incremento de la versión principal se realiza a mano cuando tenemos cambios no compatibles con versiones anteriores, reescrituras desde cero u otras razones hechas caso por caso.
dietbuddha
fuente
Pero si tiene que completar una serie de mejoras en una <Minor Version>, 1.0.0, por ejemplo. ¿Necesita hacer TODAS estas mejoras para poder decir "OK! Ahora esta es la versión 1.0.0" o incremente a la versión 1.0.0 tan pronto como se complete la primera mejora?
ahmed
@ahmed He visto el enfoque que 1.4.2es "este conjunto de correcciones, y cualquier otra cosa lista en ese momento" ... También he visto 1.4.2como "Esto se lanzará en esta fecha con lo que esté listo". Depende de su ciclo de lanzamiento.
55
@ahmed Si el criterio para pasar de 0.xx a 1.xx fuera la finalización de un conjunto de características / correcciones, entonces solo aumentaría una vez que se hubieran completado. Nota: que no trabajamos de esa manera en absoluto. No apuntamos a una versión y decidimos qué arreglos hay en ella. Apuntamos a las soluciones. La versión que obtenemos es puramente para el seguimiento y la identificación, no un objetivo.
dietbuddha
Esto es exactamente lo que quería saber :)
ahmed
21

Los números de versión solo son relevantes para las versiones , ya que son una forma para que los usuarios externos identifiquen una compilación específica de su software. Si solo estás ocupado desarrollando y no lanzando cada arreglo individualmente, entonces no te preocupes por incrementar el número de lanzamiento para cada arreglo. No es relevante para usuarios externos y pierde su propio tiempo con la contabilidad de versiones adicionales.

Greg Hewgill
fuente
¿Esto se aplica también al desarrollo web donde una versión puede ser una simple revisión de un error menor?
Ahmed
44
¿Hace QA antes de emitir la revisión? Es un lanzamiento. Si no es del producto completo, entonces de la revisión.
Peter K.
@ahmed En tal escenario, los números de versión a menudo son invisibles para el usuario y, por lo tanto, no tienen sentido (los números de versión existen principalmente para marketing y soporte técnico, los cuales no se aplican a muchas aplicaciones web). Solo usar la ID de confirmación puede ser suficiente. Si insiste en usar números de versión, sí, probablemente incremente el nivel de parche.
amon
Estoy aprendiendo muchas cosas aquí: p Entonces, para resumir: NO necesito números de versión ya que las ID de confirmación son suficientes, ya que TODOS los usuarios usarán la última versión de todos modos.
Ahmed
2
Aunque todos los usuarios están en la misma versión, cuando revise el informe de defectos, la versión habrá avanzado. Aún necesita una forma de vincular el informe a una compilación específica del software (la fecha / hora puede ser lo suficientemente buena).
mattnz
2

Para las aplicaciones web implementadas continuamente, tendemos a construir números de compilación utilizando symver por adelantado y un número de compilación, es decir: 2.5.3.4328, donde 4328 proviene del sistema de integración continua. La expectativa general es que los números cambian por pasos deliberados, pero que el número de compilación es la verdadera identificación única.

Lo que parece estar haciendo aquí es capturar el día de la implementación y el número de compilación svn relacionado:

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

Por lo que vale.

Wyatt Barnett
fuente
0

Las otras respuestas ya son geniales, así que solo agregaré encima de ellas. Si su software no se publica y realmente no necesita versiones públicas (la versión no pública es su VCS), entonces agregue la palabra clave " SNAPSHOT " al final de su versión. Algunos sistemas, especialmente en la gestión de dependencias, tratan las instantáneas de manera diferente a las versiones publicadas, ya que comparan la fecha de cambio de las instantáneas en lugar del número de versión. Entonces, si tuvo un v. 1.0.0-SNAPSHOT de 8am en un repositorio de paquetes y un descargador de dependencia local tiene la misma versión de 7am, debe descargar el actualizado del repositorio.

Como se dijo anteriormente, su sistema de control de versiones proporciona su versión privada (git, svn, etc.).

Hubert Grzeskowiak
fuente
0

Ya se ha dicho lo suficiente sobre la teoría de las versiones aquí hay otro punto de vista.

¿Cuándo debo incrementar a la versión 1.0.0?

Centraré mi respuesta en el cambio del número de versión principal.

Mi respuesta es: Básicamente cuando estás listo para ello. Pasar de 0.9 a 1.0 es una gran cosa, porque la percepción pública será que pasará de un producto beta a un lanzamiento oficial.

(Voy a asumir aquí que es un producto comercial de una compañía).

Algunas preguntas antes de pasar de 0.9 a 1.0.

¿Su organización tiene tiempo para informar a todos sus clientes actuales? Para hacer una fiesta. Obtenga muchas solicitudes de soporte. ¿Un gerente de cuenta para vender su producto? Etcétera etcétera.

Sí, veo el control de versiones como una herramienta de marketing y si miras a tu alrededor, ves que ese es básicamente el estándar de la industria.

Nuestra compañía pasó de la versión 2.x a la 3.0 y tuvo una gran fiesta, creó mucha expectación y por eso consiguió bastantes nuevos clientes. Además de algunas actualizaciones de la interfaz, las diferencias entre las versiones eran bastante menores.

Pieter B
fuente