numeración de versiones how to / 1

Una de las maneras habituales de numerar las versiones de los programas consiste en segmentar el número de versión en tres partes, de la manera 9.99.99:

  • 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.

Hace unos dias, en uno de los grupos de news que visito – xHarbour o Fivetechsoft – alguien propuso una numeración en tres segmentos, pero de la sguiente manera:

  • El primer segmento igual que antes.
  • El segundo segmento de dos dígitos, el primero del año – en este caso 4 de 2004 – y el segundo del cuatrimestre – ahora sería también 4.
  • El tercer segmento de número de build dentro de la release.

La ventaja de este segundo métido de numerar versiones es que sabes que versión es y te haces una idea de cuando fue liberada. En aplicaciones o software en que se liberan versiones continuamente esta segunda notación te hace tener claro lo actualizado o no que tienes tu software.

¿ Opiniones ? ¿ Cual os parece mejor ?

5 comentarios en «numeración de versiones how to / 1»

  1. la primera + la segunda 🙂

    Me explico, en la empresa las versiones las numeramos como indicas en la primera (mas o menos), pero luego llevan un «apellido» del tipo «mayo 2003», «noviembre 2002», así tienes las dos informaciones. Y se queda así: «Versión 2.10 de Mayo 2004»

  2. Yo creo que me gusta más el método clásico. Así puedes numerar la versión en función de lo importantes que sean los avances que has hecho, y si un usuario ve que pasas de la 4.2 a la 4.5, entenderá que ha habido cambios bastante importantes, y cuánto falta para llegar a la siguiente 5.0, aunque sea de forma aproximada.

  3. La que quieras, siempre y cuando quede especificado claramente en la documentación y/o web del proyecto el método empleado.

    Suelo emplear a.b.c. ‘a’ para cambios radicales en la funcionalidad del programa que traen alguna incompatibilidad con versiones anteriores, ‘b’ para versiones menores con novedades pero no cubiertas por ‘a’, y ‘c’ para correcciones de errores.

    Además se pueden emplear coletillas tipo: RC-, REL- o PRE-. Pero siempr explicando qué significan 😀

  4. q por favor hayga mas informacion sobre todos los icnonos de la computadora por q sino no voy a poder trabajar las tareas q me dejan en mi colegio si no encuentro q yo estoy buscando sobre la computadora.

Los comentarios están cerrados.