versioning - versionar - Conceptos básicos de la numeración de versiones?
versionamiento software ejemplo (17)
Supongamos que tengo una aplicación web con algunas funciones básicas. Quiero comercializarlo. Así que me gustaría asignar un número de versión, algo así como 0.0.1. Lo que quiero saber es si existen restricciones que deberían aplicarse a ese sistema de numeración.
Espero que hayas entendido mi pregunta, gracias de antemano.
10.50.1600.1
major.minor.build.revision
Los cambios PRINCIPALES son incompatibles con versiones anteriores y requieren cambiar el nombre del proyecto, la ruta a los archivos, los GUID, etc.
Los cambios MENORES son compatibles con versiones anteriores. Marca introducción de nuevas características.
REV para la seguridad / correcciones de errores. Compatible con versiones anteriores y posteriores.
p.ej. En el servidor SQL 2008, el número de versión RTM es 10.00.1600.22 y en el servidor SQL 2012 la versión es 11.00.2100.60
El primer campo se cambia debido a un cambio en el nombre del proyecto, es decir, 10 y 11
En el servidor SQL Server 2008 R2, el número de la versión RTM es 10.50.1600.1 y en el servidor SQL 2008 la versión es 11.00.1600.22
El segundo campo se cambia debido a la introducción de nuevas características.
Tercer campo indica construir (desarrollado)
El campo siguiente indica revisión, es decir, revisiones aplicadas ...
¿Qué hay del software que no se distribuye al público como un código fuente de correo web? ¿Crees que el número de compilación o corrección de errores sigue siendo importante en este caso?
Al desarrollar bibliotecas de software, recomiendo usar el número de versión para comunicar el nivel de compatibilidad de origen y binario entre dos versiones.
Dado que está desarrollando una aplicación web, un número de versión de dos partes probablemente sea suficiente. La primera parte es para la nueva funcionalidad y la segunda para las correcciones.
Después de leer muchos artículos / QAs / FAQs / libros, me vuelvo a pensar que [MAJOR]. [MINOR]. [REV] es el esquema de versión más útil para describir la compatibilidad entre la versión del proyecto (esquema de versión para desarrollador, no para marketing) .
Los cambios PRINCIPALES son incompatibles con versiones anteriores y requieren cambiar el nombre del proyecto, la ruta a los archivos, los GUID, etc.
Los cambios MENORES son compatibles con versiones anteriores. Marca introducción de nuevas características.
REV para la seguridad / correcciones de errores. Compatible con versiones anteriores y posteriores.
Este esquema de versiones inspirado en la semántica de las versiones de libtool y en los artículos:
http://www106.pair.com/rhp/parallel.html
NOTA: También recomiendo proporcionar compilación / fecha / personalización / calidad como información adicional (número de compilación, fecha de compilación, nombre del cliente, calidad del lanzamiento):
Hola, la aplicación v2.6.34 para National bank , 2011-05-03 , beta , compilación 23545
¡Pero esta información no es información de versión!
Echa un vistazo here . python setuptools tiene una especificación muy interesante y clara para la numeración de versiones. Estoy seguro de que puedes obtener algunos consejos muy perspicaces de ello.
La mayoría de los lugares usan algo como esto:
Major Release.Minor Release.Hot Fix.Build
Sus números de versión se verían como 1.5.0.15, etc.
Los números de versión no son una especificación concreta en el desarrollo de software.
En otras palabras, un equipo puede usar 1.0.0.0 , otros pueden usar 1.0.0 y así sucesivamente. No importa .
Simplemente elige algo que funcione para ti.
Por major.minor.revision general, major.minor.revision es el método más simple y directo de usar. Visual Studio, por ejemplo, puede asignar números de versión automáticamente para usted, al igual que otras herramientas. Así que todo lo que debe actualizar es los valores mayor / menor. Los números de compilación / revisión se actualizan automáticamente.
Me parece recordar que en los viejos tiempos (estoy hablando de Commodore aquí) usamos una sintaxis como release.version.revision que podría agregarse con una corrección y / o compilación, donde una corrección generalmente sería una letra pegada directamente a la revisión . Así que un número completo leería algo como:
2.1.44a.786
Pero como la mayoría ya ha dicho, realmente no importa, no hay un estándar verdadero para esto. Solo usa lo que sea más conveniente para ti.
Puede utilizar cualquier forma de numeración de versión que desee.
Solo recomiendo usar algo que tenga sentido. La numeración Major.Minor.Revision es popular, pero cualquier esquema de numeración que desee es "válido".
Puedes usar los números que quieras en tus versiones, ¿quién te va a restringir?
Si quieres que tu primera versión sea 0.0.0.0.0.0.0.1, está bien, aunque sea un poco tonto. Si quieres que tu primera versión sea 106.3, también puedes hacerlo, pero eso es un poco más ridículo.
Consulte el artículo de Wikipedia sobre Versiones de software para obtener ideas probadas y verdaderas de esquemas de numeración de versiones realistas.
Que yo sepa, hasta ahora no hay ninguna agencia gubernamental que dicte cómo se numeran las versiones. Pero no te preocupes, estoy seguro de que llegará pronto.
Lo mismo ocurre con aquellos que sugieren mayor-punto-menor-revisión. Mi enfoque general es: Los cambios importantes obtienen una nueva versión principal. Al igual que, si hemos añadido nuevas características importantes. Los pequeños cambios, como la adición de algunas características de conveniencia o un nuevo informe, obtienen una revisión menor. Los cambios de corrección de errores en caliente obtienen una revisión.
Definitivamente evitaría llamar a su primera versión publicada "0.l" por razones de mercadeo simples: los números menores a 1.0 suenan como una versión preliminar o una versión beta. He sabido que la gente llama a su primera versión 2.3 o algo así para hacer que parezca que ha existido un poco para inspirar más confianza, aunque eso me parece un poco deshonesto.
Realmente no importa, siempre que pueda usar el número de versión para identificar sus versiones (es decir, agregue el número de revisión interna de su sistema de control de origen al número de versión) o utilícelo para etiquetar sus lanzamientos.
Cuando lo haga, es posible que desee usar ese número como su tercer (o cuarto) componente. Parece confuso si algunos productos saltan de la versión 1.12345 a la 2.12346, pero el salto de la 1.4.12345 a la 2.0.12345 es más común.
Acerca de qué número comenzar, solo quiero citar a Eric S. Raymond :
En el mundo de código cerrado, la versión 1.0 significa "No toque esto si es prudente"; en el mundo de código abierto, se lee algo más como "Los desarrolladores están dispuestos a apostar su reputación en esto".
Siempre he usado (reescribir). (Función agregada). (Corrección de errores).
Pero establece tus propias reglas y hazlas públicas para que tus usuarios las entiendan.
Una gran cantidad de software libre utiliza un sistema de tres puntos: XYZ donde
- X es para las versiones de última hora de compatibilidad.
- Y es para otros lanzamientos, con números pares que son estables y números impares que son inestables.
- Z es para arreglos.
De esta manera, la versión 0.28.1 es una versión estable con una solución y 2.9.0 es una versión alfa con cero soluciones.
Algunas personas también se divierten desarrollando sus propios esquemas. Por ejemplo, Tex que por cada versión se aproxima a Pi, con números de versión: 3, 3.1, 3.14, etc.
Usamos major.minor.revision.build donde revisión es la revisión SVN y compilación es el número de compilación que se basa en la fecha actual (en formato YYDDD donde YY es el año y DDD es el número del día, por lo que 18001 sería el 1 de enero de 2018 .)
Tener la revisión SVN es increíblemente útil y nos ha salvado en más de una ocasión.
he usado
Major.Minor.Release.Build 1.02.4.15
y también
Año.Mes.Fecha
2009.12.10
pero cualquier cosa que te permita hacer un seguimiento individual de las versiones funcionaría. Mientras seas consistente.