¿Quién o qué considera un software digno de llamarse versión 1.0?

Además de las otras respuestas directas, aquí está la rápida “no directriz”.

Quién es quien está a cargo de la liberación. Los números de versión en algunos trabajos en los que he trabajado fueron determinados por alguien en el departamento de marketing. En otros lugares, fue determinado por el ingeniero de construcción, generalmente en un esquema incremental simple. Es lo que quieras que sea, suponiendo que sea tu proyecto.

Lo que es … nada. Todo lo que realmente importa sobre los números de versión es que no disminuyen y a nadie le importan realmente.

Tradicionalmente , la versión principal representa un cambio significativo en la funcionalidad o premisa; pasar de 1.x a 2.0 (o de 0.x a 1.0) es un gran problema que requiere una planificación avanzada para asegurarse de que los usuarios entiendan la diferencia y haya una ruta de migración para cualquier cosa que esté a punto de romper. La versión menor es el trabajo de rutina. También puede tener un número de parche para cosas que no tienen importancia y un número de compilación.

Pero la realidad es que las personas solo quieren saber si están al día. ¿La versión que estoy ejecutando es más pequeña que la que está disponible? Hora de actualizar. Y (comprensiblemente) se confunden con decimales punteados, sin tener idea de que v1.2 es mucho más antiguo que v1.12.

Algunas buenas respuestas ya, pero agregaré un poco más. Para algunos softwares, existen promesas explícitas o al menos fuertes expectativas sobre la compatibilidad entre versiones dentro de la misma versión principal. En la mayoría de los casos, esto significa que cualquier versión 1.x mantendrá compatibilidad con versiones anteriores de los protocolos y formatos de datos 1.x, cualquier versión 2.x mantendrá compatibilidad con 2.x anteriores, y así sucesivamente. Sin embargo, pasar de cualquier 1.xa 2.x puede requerir un proceso de actualización más disruptivo. Obviamente, esto es una molestia para los usuarios, pero es necesario evitar que la acumulación de códigos y pruebas de compatibilidad con versiones anteriores ralentice el desarrollo.

Volviendo a la pregunta original, entonces, 1.0 es a menudo la primera versión para la cual se hacen estas promesas. Se espera que todo lo anterior a 1.0 siga cambiando rápidamente, y a menudo de manera incompatible, con respecto a cualquier cosa anterior. Para verlo de otra manera, una parte clave de por qué 1.0 se considera listo para que los clientes lo usen (como en la respuesta de Lars Johan Olof Lidström) no es el código en sí, sino las promesas / expectativas de compatibilidad futura.

1.0.0 generalmente no es la primera versión en absoluto. Quiero decir, v1.0 significa que el software o el algoritmo que construyes hace el trabajo y cumple con los requisitos que ibas a administrar cuando comenzaste el proyecto por primera vez.

Por ejemplo, permítanme sembrar mi proyecto inacabado como ejemplo: alisentas / frag, este proyecto iba a ser un IDE HTML incorporado. Agregué muchas funcionalidades, pero al principio, mi objetivo era: elementos html editables, un IDE HTML dentro de la página HTML , por lo que aún no podía alcanzar mi objetivo. Estoy planeando cambiar las propiedades modales a una ventana como el estilo de estudio visual.
Es por eso que debería nombrar mis versiones como v1.0, puedo nombrarla v0.0.14-beta pre-alpha, etc. Pero cuando cumpla con su descripción, será v1.0.

En resumen, si su software satisface sus objetivos, sería la versión 1.0. Desde mi visión, en lugar de Dean Carpenter, la versión 1.0 no es la versión completa de un software. Todavía pueden ser un poco defectuosos (como deberían, todos los softwares deben mejorarse), pero significa una versión muy primitiva de su idea.

En general, en la programación profesional 1.0 es la primera versión de lanzamiento que le da al cliente de su cliente / jefe, independientemente de otros factores, incluso si es una basura no tan lista (debido a plazos y etc.).

Y en la programación de código abierto 1.0 la mayoría de las veces la versión que usted considera es completa y estable.

Pero en realidad los números de versión son completamente arbitrarios, puede ser cualquier número que elija, e incluso si generalmente lo incrementa con el tiempo, una versión menor puede ser “más nueva” que una versión mayor. (como Linux 2.5 vs. 2.6)

La única razón para tener cuidado con la versión con la que etiqueta algo se debe a la percepción pública. Un ejemplo fue cuando el equipo de Mozilla lanzó Firefox en versiones menores, como 7.12 a 7.13, y Google lanzó Chrome en versiones principales, como 13 a 14, y las masas sin educación comenzaron a gritar que Firefox era viejo y abandonado en comparación con Chrome, por lo que Mozilla comenzó a incrementar pequeños cambios como versiones principales también.

La respuesta de Jeff Darcy a ¿Quién o qué considera un software digno de llamarse versión 1.0? También tiene algunos buenos puntos.

Pasar de alfa a beta a la Versión 1.0 es una decisión que solo el desarrollador o el equipo de desarrollo pueden tomar. Cuando se construye un programa o proyecto (un documento, una presentación, un sitio web), una de las primeras cosas que deben presentarse son las métricas y los objetivos. ¿Qué debe hacer Product Awesome? ¿Qué debería lograr? ¿Lo está haciendo con poco o ningún error? ¿Hay suficientes personas interesadas en lo que está haciendo? ¿Necesitamos agregar más?

Lo más importante: ¿Estamos contentos con el resultado de todo este trabajo?

Cualquiera que sea el trabajo, los objetivos y las métricas deben establecerse primero. Cumplir o superar todos los objetivos en cada etapa de desarrollo es lo que mueve a un producto en la línea de tiempo de lanzamiento.

Puede variar. Todo el etiquetado de versiones es algo arbitrario. En general, 1.0 es la primera versión de lanzamiento, aunque los proyectos con un desarrollo abierto lo subvierten. En esos casos, 1.0 es la versión “completa”, con toda la funcionalidad necesaria para el concepto central, aunque aún se pueden agregar características adicionales. El significado preciso varía según su proyecto.

Me gustaría comenzar diciendo que creo que esto es subjetivo y ofrecer lo siguiente solo para describir cómo actualmente implemento las cosas.

Primero: generalmente hago poca distinción numérica en el etiquetado de mi versión entre alfa y beta.

Ambos son 0.XX para mí.

En mi mundo, mis productos generalmente entran en un estado que es al menos una UAT semiformal. El propósito de UAT para mi SDLC es asegurar que se haya entregado a las empresas un conjunto de características “suficiente” para uso de todos los usuarios aplicables. El producto puede estar en un sistema etiquetado de producción, pero la base de usuarios está limitada intencionalmente a aquellos usuarios que son expertos en la materia, evaluadores u otros que podrán contribuir a la calidad del producto de alguna manera.

Una vez que hay un “cierre de sesión” de la UAT y no hay necesidad de restricciones en los tipos de usuarios, generalmente lo llamo 1.0.0