¿Qué usar como versión inicial? [cerrado]

Normalmente comienzo mis proyectos con una versión 1.0.0. Tan pronto como tenga algunas cosas juntas, lo publico como 1.0.0 y sigo con 1.1.0.

Sin embargo, esto lleva a que la mayoría de las cosas que escribo sean utilizables, pero no exactamente, la versión completa 1.0.0. Luego agrego funciones y obtengo una versión decente en algún lugar alrededor de 1.6.0. Muchos proyectos comienzan con la versión 0.1.0, que será tan útil como mi 1.0.0.

¿Qué sugieres hacer? ¿Empezar con 1.0.0 o 0.1.0?

Por cierto, el último número es solo para versiones de corrección de errores. Puede pensar en mi 1.0.0 como 1.0 y 0.1.0 como 0.1 es más fácil para usted.

Mi control de versiones está impulsado por la configuración. Quiero que reemplace las versiones anteriores, así que lo sigo aumentando en saltos que tienen sentido para mí.

A veces, sin embargo, el control de versiones está a cargo del cliente, especialmente si está lanzando código al público.

Si es tu decisión, haz lo que funcione mejor para ti. He tenido algunos problemas con las versiones anteriores a la 1.0, así que empiezo con eso.

El estándar Semantic Versioning 2.0.0 dice:

Lo más simple que puede hacer es comenzar su versión de desarrollo inicial en 0.1.0 y luego incrementar la versión menor para cada versión posterior.

Está bien pasar de 0.3.0 directamente a 1.0.0. También está perfectamente bien estar en 0.23.0. Comenzar en 0.4.0 es algo desaconsejable, ya que sugiere que ha habido versiones publicadas anteriormente.

Además, tenga en cuenta que 0.y.zse mantiene a un lado para una iteración rápida, de modo que el desarrollo inicial (y, por lo tanto, muchos cambios importantes) no lo deje en algo tonto como 142.6.0. En lugar de agregar la versión principal, agregue la versión secundaria en cada cambio importante hasta que lance la 1.0.0:

La versión principal cero (0.yz) es para el desarrollo inicial. Todo puede cambiar en cualquier momento. La API pública no debe considerarse estable.

El número de versión depende completamente de usted. Haz lo que tenga sentido para ti y sé constante. Nadie dice que tengas que empezar desde 0, 0,0, 1,0 o 1,1.

Los grandes programadores han utilizado el sistema de numeración de versiones como bromas locales. Ejemplos (Wikipedia):

Desde la versión 3, TeX ha utilizado un sistema de numeración de versiones idiosincrásico, donde las actualizaciones se han indicado agregando un dígito extra al final del decimal, de modo que el número de versión se acerca asintóticamente a π. Esto es un reflejo del hecho de que TeX ahora es muy estable y solo se anticipan actualizaciones menores. La versión actual de TeX es 3.1415926; se actualizó por última vez en marzo de 2008

Para METAFONT:

Metafont tiene un sistema de control de versiones similar al de TeX, donde el número se acerca asintóticamente a e con cada revisión.

Finalmente, no es un número de versión, pero igualmente interesante, es que la oferta pública inicial (OPI) de Google se presentó ante la SEC para recaudar $ 2,718,281,828 (tenga en cuenta que e ~ 2.718 281 828).

Mi punto es: no sienta que necesita seguir a la multitud. Sea creativo y coherente.

Creo que aquí entran en juego diferentes factores. Se debe tener en cuenta el impacto psicológico / de marketing del número de versión (el número de versión aumenta a menudo => más $$$, la gente no quiere comprar una versión beta 0,99, etc.). Los números de versión "lógica" pueden ayudar cuando se trabaja en un equipo enorme.

Y me gusta la forma en que Linux tiene números impares para las versiones inestables y números pares para la estable.

Cuando obtengo mi primera versión utilizable lista pero no con la función completa, normalmente trato de juzgar qué tan avanzado está hacia una versión con funciones completas, así que, por ejemplo, si mi primera versión utilizable está completa al 33%, hago la versión número 0.3.0 o similar. Luego, a medida que avanzo hacia la función, las versiones correspondientes completas obtienen números dados de manera similar.

Pero una vez que pasa a la función anterior, el control de versiones completo debe cambiar

Al elegir los números de versión de un npmpaquete, tenga en cuenta que las dependencias enumeradas en los package.json rangos de semver no funcionarán por debajo de v1.0.0. Es decir,

"dependencies": {
    "my-package": "^0.5"
}

es equivalente a

"dependencies": {
    "my-package": "0.5"
}

Si desea poder usar rangos de semver, o desea permitir que otras personas los usen, es posible que desee comenzar con 1.0.0

Normalmente, el control de versiones tiene algún significado para el programador. El aumento del número principal puede indicar grandes cambios que impiden la compatibilidad con versiones anteriores. Otros números en el número de versión pueden indicar mejoras de funciones más pequeñas o correcciones de errores.

Si le preocupa que la versión 0.6.5 tenga un tono incompleto, es posible que desee comercializarla con la versión 1.0. Su número de versión de marketing no necesita coincidir con su número de versión interno. El número de versión de Windows 7, por ejemplo, es 6.1.

Mi preferencia personal es comenzar desde 0.1.0 e ir desde allí.

Depende del proyecto. Para las herramientas de línea de comandos simples, generalmente comienzo alrededor de 0.9 [.0] ya que solo considero lanzarlas o empaquetarlas cuando están cerca de completarse (o listas para la prueba beta, de todos modos). Los proyectos más complicados comienzan alrededor de 0.1 [.0] y algunos ni siquiera ven 1.0. Considero 1.0 una versión de lanzamiento (o al menos una beta probada localmente o un candidato de lanzamiento) y planifico en consecuencia.

Con los proyectos de equipo, quien pone la etiqueta de la primera versión es quien decide :).

0.1.0 es con lo que comienzo y avanzo desde allí. Esto es lo que he adaptado para Xploration By Adrian, aunque en mis primeros años era muy esporádico y usaba 1.0.0, 0.0.1 y algunos otros. Pero recomiendo comenzar en 0.1.0 y continuar desde allí.

Según Semver, reserve a y c en abc para A. Su primer lanzamiento oficial y C. Correcciones de errores y parches. Esto se debe a que una versión principal generalmente rompe el código más antiguo. Y los parches simplemente corrigen errores. Todo esto es preferencia personal, 0.99.0 no significa que tenga que ir a 1.0.0, etc. He visto algunos que van hasta 0.218.42.

Los números de versión deberían tener un significado para usted, como Arrieta comentó correctamente antes.

Tal vez siguiendo algo como: First # es la versión principal, Second # es la misma versión principal con algunas características agregadas y Third # es la misma versión principal, con las mismas características pero con errores corregidos o cambios pequeños (pero lo suficientemente significativos) agregados.

1.3.2 => Primera versión, con más funciones y algunos errores corregidos.

Sin embargo, para los usuarios finales, algunos están acostumbrados a grandes números para lanzamientos finales.

Por ejemplo: Corel 8, para 8.0.0, 8.0.1, 8.2.2, etc. Corel 9, para 9.0.0 ... etc.

Y sobre todo se trata más de estrategias de marketing como: Corel X5 en lugar de Corel 15.0.2, por ejemplo.

Yo diría que depende de si el número de versión es para ti o para el cliente.

comience con 0.0.0 y continúe desde allí.

Comience con 1.1.1 y continúe desde allí.