Realmente depende del proyecto; Algunos proyectos ni siquiera lanzan una versión 1.0.
Los desarrolladores de MAME no tienen la intención de lanzar una versión 1.0 de su programa emulador. El argumento es que nunca estará realmente "terminado" porque siempre habrá más juegos de arcade. La versión 0.99 fue seguida simplemente por la versión 0.100 (versión menor 100> 99). De manera similar, Xfire 1.99 fue seguido por 1.100. Después de 6 años de desarrollo, eMule ni siquiera ha alcanzado la versión 0.50 todavía. Versiones de software en Wikipedia
Un método popular de numeración de versiones (que he comenzado a usar) es el control de versiones semántico .
Bajo este esquema, los números de versión y la forma en que cambian transmiten significado sobre el código subyacente y lo que se ha modificado de una versión a la siguiente.
Algunas citas para darle más ideas sobre cómo funciona y / o responder algunas de sus preguntas:
¿Cómo sé cuándo lanzar 1.0.0?
Si su software se está utilizando en producción, probablemente ya debería ser 1.0.0. Si tiene una API estable de la que dependen los usuarios, debe ser 1.0.0. Si te preocupa mucho la compatibilidad con versiones anteriores, probablemente ya deberías ser 1.0.0.
¿No desalienta esto el desarrollo rápido y la iteración rápida?
La versión principal cero se trata de un desarrollo rápido. Si está cambiando la API todos los días, debería estar en la versión 0.xx o en una rama de desarrollo separada trabajando en la próxima versión principal.
Si incluso los cambios incompatibles hacia atrás más pequeños en la API pública requieren un aumento importante de la versión, ¿no terminaré en la versión 42.0.0 muy rápidamente?
Esta es una cuestión de desarrollo responsable y previsión. Los cambios incompatibles no se deben introducir a la ligera en el software que tiene mucho código dependiente. El costo en el que se debe incurrir para actualizar puede ser significativo. Tener que superar las versiones principales para liberar cambios incompatibles significa que considerará el impacto de sus cambios y evaluará la relación costo / beneficio involucrada.
También hay reglas sobre cómo especificar versiones "alfa", "beta", etc. Consulte los detalles en http://semver.org/ .
[Editar] Otro esquema interesante de numeración de versiones es el que utiliza MongoDB :
MongoDB usa las versiones impares para los lanzamientos de desarrollo.
Hay 3 números en una versión de MongoDB: ABC
- A es la versión principal. Esto rara vez cambiará y significará cambios muy grandes
- B es el número de lanzamiento. Esto incluirá muchos cambios, incluidas características y cosas que posiblemente rompan la compatibilidad con versiones anteriores. Incluso los Bs serán ramas estables, y los impares serán desarrollo.
- C es el número de revisión y se utilizará para errores y problemas de seguridad.
Por ejemplo:
- 1.0.0: primer lanzamiento de GA
- 1.0.x: correcciones de errores a 1.0.x: muy recomendable para actualizar, muy poco riesgo
- 1.1.x: versión de desarrollo. Esto incluirá nuevas características que no están completamente terminadas y que están en progreso. Algunas cosas pueden ser diferentes a 1.0
- 1.2.x: segunda versión de GA. Esta será la culminación de la versión 1.1.x.
No creo que haya un "estándar" como tal.
Existe una convención para Release Candidates que generalmente es "[versión] RC 1", etc., dependiendo de cuántas versiones creas que puedes lanzar.
Si está lanzando una versión muy temprana de su producto, una que no tiene la función completa, es posible que desee utilizar la versión "0". De esa manera, puede incrementar la versión con el tiempo a medida que completa su conjunto de funciones.
Usaría "Alpha" y "Beta" como Release Candidate, por versiones de tiempo limitado para indicar que crees que estás cerca de lanzar la versión completa.
fuente
Hay una página de Wikipedia sobre versiones de software . Para compartir versiones anteriores a la 1.0, la convención utilizada por Apple y otros funciona bien: major.minor.maintSrev donde S es el indicador de etapa para las versiones preliminares: d = desarrollo, a = alfa, b = beta, rc = candidato de lanzamiento. Entonces, su primera versión interna podría ser 1.0.0d1.
Para revisiones completamente internas, la marca de tiempo es suficiente.
fuente
Cada desarrollador en su mayor parte decide qué estándar van a utilizar. En general, aunque los números a la izquierda del punto decimal indican grandes revisiones que probablemente serían muy notables para el usuario promedio (es decir, cambios en la funcionalidad o la interfaz, etc.). En el lado derecho del punto decimal, esto sería un cambio / modificación / adición que no cambió mucho la funcionalidad general y el diseño, pero sí cambió algo sobre el programa en sí (es decir, hacer una función más rápido mientras sigue haciendo lo mismo o fijo un problema de seguridad). Luego, si agrega puntos decimales adicionales, los números a la derecha de estos indicarían cambios cada vez más pequeños (es decir, correcciones de errores menores / problemas de seguridad y demás).
fuente
Como han dicho otros, no parece haber un estándar exacto. Nuestra organización utiliza la siguiente notación:
Versión 1.0 ---> 2.0 (Una característica importante nueva / mejorada agregada al producto)
Versión 1.0 ---> 1.1 (Una característica nueva / mejorada de nivel medio agregada al producto)
Versión 1.0 ---> 1.001 (correcciones de errores)
fuente
El hito de la "versión 1.0" es muy importante para los usuarios de computadoras experimentados, ya que implica que el programa está hecho y funciona como se esperaba. Cualquier cosa en la versión "0.algo" implica que los programadores mismos piensan que el programa aún no ha terminado .
Puede mantener los números de versión "0.1", "0.2" ... para los principales logros de la funcionalidad y luego subconjunto con un número de compilación que con frecuencia es una fecha y marca de tiempo suficientemente finas.
fuente