Pregunta ¿Qué usar como una versión inicial?


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

Sin embargo, esto lleva a utilizar, pero no exactamente, la versión completa 1.0.0 de la mayoría de las cosas que escribo. 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 que hagas? Comience con 1.0.0 o 0.1.0?

El último número es para versiones de corrección de errores solo por cierto. Puedes pensar que mi 1.0.0 como 1.0 y 0.1.0 como 0.1 es más fácil para ti.


75
2017-09-16 16:22


origen


Respuestas:


Mi versión está dirigida por la configuración. Quiero que reemplace versiones anteriores, así que sigo aumentando en saltos que tienen sentido para mí.

A veces, sin embargo, el control de versiones es impulsado por el cliente, especialmente si está liberando el código al público.

Si es su decisión, haga lo que sea mejor para usted. He tenido algunos problemas con las versiones anteriores a la 1.0 así que empiezo con eso.


-8



los Versión semántica 2.0.0 el estándar dice:

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

Está bien pasar de 0.3.0 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.z se mantiene a un lado para una iteración rápida, por lo que el desarrollo inicial (y por lo tanto, muchos cambios de última hora) no te deja en ridículo como 142.6.0. En lugar de golpear la versión principal, baje la versión menor en cada cambio de ruptura hasta que libere 1.0.0:

La versión principal cero (0.y.z) es para el desarrollo inicial. Cualquier cosa puede cambiar en cualquier momento. La API pública no se debe considerar estable.


124



Cuando obtengo mi primera aplicación utilizable pero no la versión completa, normalmente trato de juzgar qué tan avanzado está en una versión completa de la función, así que por ejemplo, si mi primer uso es 33% de la función completa, hago la versión número 0.3.0 o similar. Luego, a medida que avanzo hacia la función completa, las versiones correspondientes reciben números proporcionados de manera similar.

Pero una vez que te mueves en la función pasada, las versiones completas deben cambiar


1



Creo que diferentes factores entran en juego aquí. El impacto psicológico / de marketing del número de versión (el número de versión aumentó a menudo => más $$$, las personas no quieren comprar una versión beta de 0,99, etc.) deben tenerse en cuenta. Los números de versión "lógica" pueden ayudar cuando se trabaja en un gran equipo.

Y me gusta la forma de Linux de tener números impares para las versiones inestables, e incluso números para el estable.


1



El número de versión es totalmente de usted. Haz lo que tiene sentido  y se constante. Nadie dice que debe comenzar desde 0, o 0.0, o 1.0, o 1.1.

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

Desde la versión 3, TeX ha utilizado una   numeración idiosincrásica de la versión   sistema, donde las actualizaciones han sido   indicado al agregar un dígito extra en   el final del decimal, para que   número de versión asintóticamente   se aproxima a π. Esto es un reflejo de   el hecho de que TeX ahora es muy estable,   y solo actualizaciones menores son   anticipado. La versión actual de   TeX es 3.1415926; fue actualizado por última vez   en marzo de 2008

Para METAFONT:

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

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

Mi punto es: no sientas que debes seguir a la multitud. Se creativo y consistente.


1



Normalmente, el control de versiones tiene algún significado para el programador. Aumentar el número principal podría 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 te preocupa que la versión 0.6.5 tenga un timbre incompleto, es posible que quieras comercializarla en la versión 1.0. Su número de versión de comercialización no necesita coincidir con su número de versión interna. 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í.


0



Al elegir números de versión para un npm paquete, tenga en cuenta que para las dependencias enumeradas en package.json  gamas secas no funcionará 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 temperatura, o si desea permitir que otras personas los usen, es posible que desee comenzar con 1.0.0


0



Depende del proyecto Para las herramientas simples de línea de comandos, generalmente empiezo alrededor de 0.9 [.0] ya que solo considero liberarlas o empacarlas cuando estén casi terminadas (o listas para la prueba beta, de todos modos). Los proyectos más complicados comienzan alrededor de 0.1 [.0] y algunos nunca ven 1.0. Considero 1.0 una versión de lanzamiento (o al menos una versión beta probada localmente o candidato de lanzamiento) y plan en consecuencia.

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


-1



Los números de versión deben ser significativos para usted como Arrieta correctamente comentado antes.

Tal vez después de algo como: First # es el lanzamiento del alcalde, Second # es el mismo lanzamiento del alcalde con algunas características añadidas y Third # es el mismo lanzamiento del alcalde, con las mismas características pero con errores solucionados o pequeños cambios añadidos (pero lo suficientemente significativos).

1.3.2 => 1st Release, con más características y algunos errores corregidos.

Sin embargo, para los usuarios finales, algunos están acostumbrados a los números grandes para las versiones 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 usted o para el cliente.


-2