Supongamos que tengo una aplicación web con algunas funciones básicas. Quiero comercializarlo. Entonces me gustaría asignar un número de versión, algo así como 0.0.1. Lo que quiero saber es si hay alguna restricción que se deba aplicar a ese sistema de numeración.Conceptos básicos de numeración de la versión?
Espero que haya entendido mi pregunta, gracias de antemano.
mayoría de los lugares usar algo como esto:
Mayor Release.Minor Release.Hot Fix.Build
Sus números de versión se vería 1.5.0.15, etc.
Puede usar cualquier forma de numeración de versión que desee.
Simplemente 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".
sí, ver por ejemplo MS Windows: 95, 4.0, 98, 2000, XP, Vista, 7 –
@just: Esas son "versiones comerciales". Si cavas en algún lugar, encontrarás la versión oficial de desarrollo. –
Esos fueron nombres de productos, no números de versión. –
Puede usar los números que desee en su versión, ¿quién lo va a restringir?
Si quiere que su 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, puedes hacerlo también, pero eso es un poco más ridículo.
Consulte Wikipedia article on Software Versioning para obtener algunas ideas comprobadas de esquemas de numeración de versiones realistas.
Es posible que desee empezar echando un vistazo al artículo Software versioning en wikipedia, que proporciona algunas informaciones sobre las posibilidades que tiene ;-)
Podría darle algunas ideas de lo que podría hacer en su caso específico ...
Siempre he usado (reescribo). (Función añadida). (Corrección de errores).
Pero establezca sus propias reglas y haga que sean públicas para que los usuarios las entiendan.
me gusta que haya logrado describir major.minor.patch, pero lo hizo reemplazando los términos normales con lo que realmente significan. Mucho más fácil de entender rápidamente. – Harvey
He usado
Major.Minor.Release.Build 1.02.4.15
y también
Year.Month.Date
2009.12.10
pero cualquier cosa que le permita rastrear individualmente los lanzamientos funcionaría. Mientras seas consistente.
Utilizamos major.minor.revision.build donde revisión es la revisión SVN y acumulació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 el número del día, entonces 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.
Echa un vistazo a here.python setuptools tiene una especificación muy interesante y clara para la numeración de versiones. Estoy seguro de que puede obtener algunas pistas muy perspicaces de ella.
Que yo sepa, hasta el momento no existe una agencia del gobierno que dicte cómo numera las versiones. Pero no te preocupes, estoy seguro de que llegará pronto.
Lo mismo para los que sugieren revisión de punto-mayor-menor. Mi enfoque general es: los cambios importantes obtienen una nueva versión principal. Al igual que si agregamos nuevas funciones importantes. Pequeños cambios, como algunas características de conveniencia agregadas o un nuevo informe, obtienen una revisión menor. Los cambios de corrección de errores se obtienen una revisión.
Definitivamente evitaría llamar a su primera versión publicada "0.l" por simples razones de marketing: 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í solo para que parezca que ha estado por un tiempo inspirar más confianza, aunque eso me parece un poco deshonesto.
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 elija algo que funcione para usted.
Por lo general, major.minor.revision es el método más simple y sencillo de usar. Visual Studio, por ejemplo, puede asignar números de versión automáticamente, al igual que otras herramientas. Por lo tanto, todo lo que debe actualizar es los valores mayor/menor. Los números de compilación/revisión se actualizan automáticamente.
Una gran cantidad de software libre utiliza un sistema de tres puntos: x.y.z donde
Esta versión de manera 0.28.1 es una versión estable con una solución y 2.9.0 es una versión alfa con cero arreglos.
Algunas personas también se divierten desarrollando sus propios esquemas. P.ej. Tex que por cada lanzamiento se acercaba a Pi, con números de versión: 3, 3.1, 3.14, etc.
+1 para señalar la modificación con número impar –
Realmente no importa, siempre y cuando pueda usar el número de versión para identificar sus versiones (es decir, agregue su control de fuente) número de revisión interna del sistema en el número de versión) o úselo para etiquetar sus lanzamientos.
Al hacerlo, es posible que desee utilizar ese número como su tercer (o cuarto) componente. Parece confuso si algún producto salta de la versión 1.12345 a 2.12346, pero saltar de 1.4.12345 a 2.0.12345 es más común.
Sobre qué número para empezar, sólo quiero citar Eric S. Raymond:
En el mundo de código cerrado, Versión 1.0 medios "No toque esto si usted es prudente."; En el mundo de código abierto se lee algo más parecido a 'Los desarrolladores están dispuestos a apostar sus reputación en este'
+1 para el final() – RCIX
Creo recordar que en los viejos días (estoy hablando Commodore aquí.) utilizamos una sintaxis como release.version.revision que se puede agregar con arreglo y/o compilación, donde la corrección suele ser una letra pegada directamente a la revisión. Por lo tanto, un número completo sería algo como:
2.1.44a.786
Pero como la mayoría ya ha dicho, en realidad no importa, no hay un verdadero estándar para esto. Solo usa lo que sea más conveniente para ti.
¿qué hay del software que no se distribuye al público como un código fuente de webmail? ¿Crees que el número de compilación o corrección de fallas sigue siendo importante en este caso?
Al desarrollar bibliotecas de software, I recommend usando el número de versión para comunicar el nivel de compatibilidad fuente y binaria entre dos versiones.
Dado que está desarrollando una aplicación web, probablemente sea suficiente un número de versión de dos partes. La primera parte es para nuevas funcionalidades y la segunda es para soluciones.
Después de leer un montón de artículos/QA/Preguntas frecuentes/libros me vuelvo a pensar que [MAYOR]. [MINOR]. [REV] es el esquema de versiones más útil para describir la compatibilidad entre la versión del proyecto (esquema de versiones para desarrollador, no para marketing).
PRINCIPALES cambios es hacia atrás incompatibles y requieren cambiar nombre del proyecto, ruta de los archivos, GUID, etc.
MINOR cambios es compatible con versiones anteriores. Marque la introducción de las nuevas características .
REV para la seguridad/corrección de errores. Adelante hacia adelante y hacia atrás.
Este esquema de versiones inspirado por libtool la semántica de versiones y por los artículos:
http://www106.pair.com/rhp/parallel.html
NOTA: También recomiendo proporcionar acumulación/fecha/custom/calidad información como adicionales (Build número, fecha de compilación, nombre del cliente, calidad de lanzamiento):
Hola aplicación v2.6.34 para Banco Nacional, 2011-05-03, beta, construir
Pero esta información es no versiones de información !!
10.50.1600.1
major.minor.build.revision
cambios importantes es incompatible hacia atrás y requieren el cambio de nombre del proyecto, la ruta a los archivos, GUID, etc.
cambios de menor importancia es compatible con versiones anteriores. Marque la introducción de nuevas características.
REV para la seguridad/corrección de errores. Adelante hacia adelante y hacia atrás.
por ejemplo. En SQL Server 2008 RTM número de versión es 10.00.1600.22 y en SQL Server 2012 versión es 11.00.2100.60
primer campo se cambia debido al cambio de nombre del proyecto es decir, 10 y 11
en el servidor SQL 2008 R2 RTM versión número es 10.50.1600.1 y en la versión de SQL Server 2008 es 11.00.1600.22
El segundo campo se cambió debido a la introducción de nuevas características.
tercer campo indican construir (desarrollado)
Forth campo indica revisión es decir, revisiones aplicadas ...
Qué tipo de aplicación es todo, y con qué frecuencia piensa usted que va a hacer cambios? ¿Tienes algún tipo de línea de tiempo? ¿Cuántos usuarios lo usarían? –
actualización depende de las características o versiones corregidas de errores. El número de usuarios no es una preocupación – coderex
lo siento, no tengo ningún sistema de control de versiones. solo quiero obtener un conocimiento básico sobre esto. porque supongo que debo transferir un sitio web, así que quiero mantener el sistema de versiones. – coderex