Versiones de software
Buenas tardes, alguien podría ayudarme a saber cómo se manejan las versiones de software?
He visto cosas que dicen RC, SNAPSHOT, la numeración de librerías cambia mucho de una a otra
Agradecería mucho esta ayuda porque ya he buscado pero sigo con dudas, aún no me queda claro esto
- hobo_75's blog
- Inicie sesión o regístrese para enviar comentarios
¿Versiones software?
¿A qué te refieres?
Lo que yo entiendo de versiones de software es cuando surge una actualización o cambio del mismo. Por ejemplo, Java2,Java3,...,JavaN. O Windows 98,2000,XP , Vista o 7
"He visto cosas que dicen RC, SNAPSHOT, la numeración de librerías cambia mucho de una a otra"
Tal vez te refieres a que "aumenta el número de librerías", esto pasa cuando actualizan un software, implementando nuevas funciones. Se supone que el fabricante se encarga de eso.
Puedes checar esta página:http://es.wikipedia.org/wiki/Control_de_versiones
Tal vez te sirva esto
Esto lo saqué de FOROS DEL WEB
Una de las maneras de numerar las versiones de programas consiste en segmentar el número de versión en tres partes, de la manera X.XX.XX:
* El primer segmento es el número de versión propiamente dicho, que se cambia cuando se trata de una revisión en profundidad del programa.
* El segundo segmento es el número de release, que cambia cuando se hace un cambio de funcionalidad importante en el programa, pero no tan importante como para que sea un cambio de versión. Además existe la costumbre de que las los números impares de release son inestables, mientras que cuando se llega a una versión estable se cambia a un número par.
* El tercer segmento es el numero de build dentro de la release.
Tambien esta el que numera las versiones segun se vaya incrementando en cuanto a funcionalidad.
Muchas veces, suelen poner al finalizar el numero de version la letra "b" que significa beta.
Pero se supone que esto solo lo hacen los fabricantes.
Y puedas checar mas info en
Cristalab
gracias
Gracias por la info, tengo 3 preguntas más
según tu experiencia, cómo es la numeración de versiones, cómo lo haces tú?
para que sirve eso de snapshot?
cuál es el patrón más utilizado para numerar las versiones?
gracias
gracias
Otra preguntita
cómo se puede automatizar esto, osea que el IDE o maven, o ant o lo que sea te vaya cambiando la versión cada que haces un rebuild?
gracias por tu tiempo
Creo!
Creo! la verdad no se mucho sobre eso pero al parecer en maven.
Ve estas página
Sobre versiones de software:
Versiones de software
Estados y versiones del Sw
Busca versiones del software en Google...hay info que te puede servir. Yo nunca he tenido que numerar una versión de software Se supone que eso lo hacen los distribuidores y fabricantes.
Hola CARRARO, gracias por
Hola CARRARO, gracias por las ligas
Yo nunca he tenido que numerar una versión de software Se supone que eso lo hacen los distribuidores y fabricantes.
Ok
Y que hay acerca de los snapshots, alguien que tenga experiencia con esto del versionado ?
Gracias
RE: Gracias
@hobo_75
Maven es un sistema de manejo de proyecto de principio a fin en el ciclo de desarrollo de software. La versión la especificas en el fichero pom.xml, y la versión se recomienda cambiar cuando vas a añadir o ha realizar una mejora grande (después de congelar y llegar a una versión estable de un producto -proyecto-).
Por lo general cuando haces el snapshot de la versión estable y probada se le deja cómo versión 1.0...versiones de prueba son por módulo supongamos tienes el módulo de ventas y el de compras...la versión para el proyecto con el módulo de ventas podría ser la 0.1.x (donde x, es la revisión o numero de corrección de errores que has llevado)...Luego la versión para el proyecto con el módulo de compras podría ser la 0.2.x...y la integración de la versión 0.1.x y 0.2.x puede llamarse versión 1.0.
No sé el manejo de nombramiento de versiones es según el desarrollador...también mucha gente la maneja por el número de veces que ha compilado (Microsoft es lo que hace).
SNAPSHOT, es lo que muchas personas por convención utilizan para el nombramiento de versiones, pero puede ser configurada también en tu fichero pom.xml de maven...es sólo el "etiquetado" después del nombre del producto...digamos que en tu pom la versión es "1.0-MySoftIsMine", cuando empaquetes (con maven) tu proyecto quedará un fichero cómo "Miprogramin-1.0-MySoftIsMine.war"...Puedes checar en Google sobre convenciones de Maven2.
Espero que te ayude.
RC, snapshot, etc
La traducción de snapshot es fotografía. Maven por default a tus proyectos les pones algo como 0.1-SNAPSHOT pero tú le puedes poner la versión que tú quieras. La numeración en versiones generalmente es que el número entero es la versión mayor, luego la versión menor, luego la versión de release y en cuarto lugar el build, aunque el build solamente es para cuando estás usando lo más más más reciente de una librería o programa, recién salidito del horno.
La versión mayor solamente debe cambiar cuando hay cambios muy significativos en el software. En el caso de un framework por ejemplo, el cambio en versión mayor debe darse solamente cuando han cambiado el API, las clases que contiene, reescribieron el framework parcial o totalmente, etc. La versión menor significa que hubo mejoras a la funcionalidad existente y probablemente haya funcionalidad nueva pero no se ha modificado la existente; puede haber optimizaciones en algunas partes, etc pero se supone que la puedes seguir usando como antes sin tener problemas. El release cambia cuando sacaron la mismita versión de la librería pero con correcciones de algunos defectos que hayan encontrado.
Eso de nones y pares para versiones estables o inestables solamente lo he visto en el kernel de Linux, no es algo estándar.
Una versión beta es cuando ya se tiene completa la funcionalidad pero no se ha probado por completo, puede tener algunos defectos, la idea de distribuir software en beta es que los usuarios reporten los problemas que encuentren. Por cierto eso de "beta" viene de la novela de Aldous Huxley, Un Mundo Feliz, donde los betas eran como de segunda clase.
Una versión alfa es cuando todavía no está ni terminado el software pero se hace disponible al público por si alguien quiere usar lo que ya se tenga terminado, un subconjunto de la funcionalidad planeada. Eso se acostumbra mucho en software libre; en software comercial normalmente se maneja sólo con algunos clientes que el fabricante considere muy importantes o especiales.
RC significa "Release Candidate", viene después de una beta (puede haber varias betas, por eso luego ves versiones como 1.0b1 o 1.0b3 etc) y se supone que ya todo funciona como debe, pero todavía no se ha podido probar todo; se han corregido los defectos que surgieron en las betas pero esos son los que estaban en la funcionalidad más utilizada, todavía podría haber alguna bronca en funcionalidad que sólo unos pocos usuarios utilicen. Puede haber varios candidatos, por eso ves versiones como 1.0RC1, 1.0RC2 (el RC2 salió porque algo estaba mal en la RC1).
En la versión mayor a veces ves un cero, eso es también una manera de indicar que el software todavía no está completo, pero no es lo mismo que una beta; esto es común en software libre, significa que puedes usar solamente algunas cosas de lo que planean tener en la versión completa, pero ya están probadas y funcionan bien.
Las versiones mayor, menor y release se separan por puntos decimales pero eso no significa que por ejemplo después de la versión 0.9 ya tienen que sacar la 1.0, pueden sacar todavía la 0.10, 0.11, 0.12, etc.
Algunos ejemplos:
Log4J 1.0 ya tenía bien definida la funcionalidad ofrecida.
Log4J 1.1 y 1.2 incluían más medios para guardar bitácoras y también más interfaces con otros frameworks (como java.util.logging que no existía cuando salió Log4J)
Desde la 1.2.1 hasta la 1.2.16 solamente han incluido correcciones y optimizaciones.
Hay una versión 2.0 que se considera experimental todavía, reescribieron muchas cosas y el API cambia de manera significativa, son cambios que aprovechan cosas de Java 5.
En tu software puedes manejar todo este rollo de las versiones si es que lo piensas distribuir, porque es muy útil para los usuarios ya que es la manera en que saben qué tan significativos son los cambios que puede haber de una versión a otra. Es decir si sacas tu software en versión 1.0 y luego sacas la 1.0.1 con eso yo sé que puedo instalarlo sin preocuparme de que haya que reescribir partes de mi software que usan tu librería, pero que seguramente corregiste algún defecto que yo ni sabía que tenía pero pues ya leyendo las notas sobre la nueva versión sabré si realmente la necesito instalar o no (tal vez corregiste alguna vulnerabilidad o algun defecto que hacía que el software tronara como ejote bajo ciertas circunstancias extremas, etc).
Si trabajas en una empresa de desarrollo, es importante mantener versiones internamente, aunque sea solamente un número entero, que sea el que te da tu sistema de control de versiones; así, si por ejemplo tienes un cliente al que le hiciste un sistema pero reutilizaste algunos componentes que ya tienen hechos y luego de 5 años te pide que le hagas unas mejoras o que se lo adaptes a una nueva versión del sistema operativo que usan, porque ya no corre en el más reciente, etc, si sabes qué versión de todos los fuentes usaste para compilarle su aplicación, solamente extraes esa misma versión de todo y a partir de ahí ya ves si tienes que cambiar algo. Y así no te topas con que tienes que reescribir una buena parte del software de ese cliente porque ya no compila con las versiones más recientes de tus componentes, que han cambiado bastante en 5 años.
En fin creo que me extendí un poco pero espero te sirva el megachoro.
Excelente respuesta
En fin creo que me extendí un poco pero espero te sirva el megachoro.
Pero por supuesto que me sirve, gracias, gracias y más gracias. Excelente respuesta
Con esto ya tengo más claro cómo versionar algunas librerías que tengo planeadas, de verdad que me has ayudado mucho y te agradezco infinitamente el tiempo que te has tomado en responder las dudas de un desconocido.
Ya me queda claro los los números de la versión y las letras griegas, así como los Release candidates, pero
La única dudilla que me sigue quedando es en qué momentos utilizar la palabra snapshot?, si lo hace maven por default ha de ser por algo bueno...
infinitas gracias
Snapshot
El snapshot es una versión inestable, solamente es el resultado de la última compilación. Si bajas un snapshot es porque quieres lo último último último que los programadores del proyecto han liberado pero es probable que sea inestable.
En Maven por default tus proyectos traen lo de SNAPSHOT porque cada vez que compiles, te van a salir jars/wars/etc que normalmente serán inestables, y ya es cosa tuya ponerle después un número de versión adecuado cuando sabes que tu software ya es estable y lo vas a publicar, pero después de publicar, cualquier otro cambio que hagas, vuelves a estar generando snapshots.
Re: Snapshot
Leí que snapshot es cuando la versión va como que a medias antes del release.... me quedo con tu definición.
Gracias
Gracias
mmm Muchas gracias ezamundio. siempre he dicho no hay como una explicación casera. Que tengas un excelente día.