Caminando hacia un estandar para el Etiquetado del software en el CVS del G5

Como ya sabéis casi todos en todos los proyectos que está haciendo nuestro grupo todo el software se etiqueta con un criterio muy objetivo, que nos permite definir la calidad del software que va en cada entrega (versionado del código). Esto lo podemos hacer gracias a que seguimos un estilo de programación basada en TDD (Test Driven Development), y con la integración continua como pieza fundamental de nuestra forma de trabajar. Quiero utilizar este artículo como punto de inicio de discusión para concretar cual sería la forma mas coherente de etiquetar el software, que personalmente pienso debería permitir con el simple hecho de leer la etiqueta, tener una idea clara de cual es la calidad del software para que el cliente pueda determinar si le interesa "asumir el riesgo" de ponerlo en producción.

Actualmente nuestra nomenclatura es la siguiente.

NOMENCLATURA DE VERSIONADO EN EL CVS

El etiquetado de las versiones en el cvs de desarrollo tiene el siguiente formato generico:

V_XX_XX_XXXX

Un ejemplo sería v_00_05_00M1. La descripción de cada uno de los caractéres y su modificación es la siguiente:

• Los dos primeros dígitos para la identificación de la versión principal, estos digitos se incrementan cuando:
  
• Hay un cambio importante en la arquitectura de la plataforma. Es decir del core o capas generales de la arquitectura de la plataforma, Servidor de aplicaciones o Base de Datos.
• Hay un incremento significativo de funcionalidades que cubre la plataforma. Normalmente estará asociado a incorporación de nuevas Capacidades o evoluciones importantes de las ya implementadas.
• Evolución en JDKs y APIs de JEE.
  

• Los dos siguientes digitos designan evoluciones moderadas para una versión principal dada. Estos dígitos se incrementan cuando:
• Hay nuevas funcionalidades y mejoras sobre la versión anterior. Normalmente estarán asociadas a incorporación de nuevas Capacidades o funcionalidades de los interfaces de usuario.
  

• Los dos últimos dígitos designan parches a la versión correspondiente.
  

• Por último se tienen los siguientes textos:
• Mx: (Mile Stone x) Designa una versión que pasa almenos el 70% de las pruebas automáticas Funcionales (JMeter) de regresión y pasa el 100% de las pruebas unitarias (JUnit) de regresión de la plataforma.
• RCx: (Release Candidate x) Designa una versión que:
• RC1: Pasa el 100% de todas, las pruebas de regresión (automáticas).
• RC2: Pasa al menos un 70% de las pruebas definidas en el plan de pruebas para dicha versión.
• RC3: Pasa las pruebas de RC1, RC2, el 95% de las pruebas definidas en el plan de pruebas para dicha versión que no estén pospuestas. Siempre que el 5% de las pruebas no pasadas no sean defectos importantes o críticos, en un estado de asignado o resolvíendose.

• Rx: (Release) Designa una versión que pasa las pruebas de RC3 y:
• Pasa las pruebas de carga definidas en el "Rendimiento de la aplicación".
• Pasa las pruebas anteriores y las de estabilidad.

• Sin texto: Es la versión estable del aplicativo donde ha pasado el100% de las pruebas de regresión, las pruebas definidas en el plan de pruebas , las pruebas de rendimiento, las pruebas de concurrencia, las pruebas de estabilidad definidas en la versión y se ha realizado una reunión entre el jefe del equipo de pruebas y el Jefe de Proyecto para aceptar los resultados del plan de pruebas.
  

DNM

192.168.5.30