Control de Versiones del Software

Si trabajas en desarrollo de software sea tu proyecto o eres participe de uno, bien sabes que tanto todo el proyecto como los paquetes que lo conforman estan sujetos a la referencia por algun nombre o numeracion que indica si es o no estable, e incluso estar etiquetado por una numeracion que indica sus anexos (paquetes, caracteristicas funcionales y correccion de errores).

Yo en lo particular he llegado a indicar la version de cualquier cosa que he creado para algunos clientes “al ojo” a como yo he considerado que ha avanzado/evolucionado y que tan madurado/preparado esta. Esto me ha llevado a volver a los origenes que me ayude a confirmarme que tan mal o bien lo he aplicado, por lo que esto trata de las busqueda y conversaciones que he tenido con algunos desarrolladores de software para indagar un poco mas, sobre el control de las versiones de software.

En muchos software veremos que en su descripcion (about/acerca de…) nos indicara su version, bien sea bajo un nombre, una numeracion-etiqueta que hace referencia a ser un paquete de determinado status o apuntado a determinada plataforma y en mas detalle a su lado, posiblemente entre parentesis ( ) la numeracion que indica que tanto ha crecido y ha mejorado y que tan estable es.

Las versiones de software nos informan mucho sobre su contexto, como comentaba, que tan empaquetado esta, anexos de funciones y correcciones, si es release o no e incluso idioma del paquete (es-AR, es-ES, es-VE, es-CO), para que plataforma esta hecho (solo algunos casos) y en otros casos, quienes son sus mantenedores por medio de una firma digital que confirma que es de una casa de software, organizacion o grupo de desarrolladores garantizando que no es una version de terceros que se haga pasar por la original. Los sistemas operativos pueden advertir ante la instalacion si la firma del software ha pasado o no su legitimidad como tal.

Wikipedia nos ofrece una documentacion muy bien explicada sobre las fases del desarrollo de software que expone lo que todos conocemos bien (versiones Alfa y Beta) y en algunos casos Gamma, Delta y Omega.  Una fase inicial del proyecto podria comenzarse como Alfa y al evolucionar un poco mas pasar a Beta, para sus momentos de vida aun inestable pero funcional.

Cuando hacemos un programa (aplicacion o servicio) siempre lo probamos, tratamos de explotarlo, de hacerlo fallar, de ser ocurrentes ‘como si realmente quisiecemos que falle’ tratando de agregar campos o manipulaciones no tan acorde a como deberia ser, esto porque -cada cabeza es un mundo- y porque muchas personas son muy ocurrentes. Incluso el que sea un sistema anti-idiotas, anti-tercos o anti-saboteadores, ofrecerle mas de una via/camino a llegar a un modulo, tips! de ayuda para guiarlo y sepa para que es ese link, boton o ventana en la que se encuentra. Validar los campos necesarios bien sea por descuido o intencion del usuario final de no haberlo hecho correctamente, confirmaciones de operaciones contra la base de datos, ya que si el usuario sin querer toca la tecla incorrecta (boton borrar, por ejemplo) podria borrar accidentalmente el registro de cliente que tiene en frente o desear crear un registro ya existente (un addnew, no un update), por lo que como sabemos bien, tenemos muchos procesos y gestiones delicadas que deben validarse bien y confirmacion por parte del usuario que es eso lo que desea hacer realmente.

Tambien tenemos la vivencia de ofrecer esa version Beta para que nos las prueben, en mi caso, directamente el cliente, esperando que esa(s) persona(s) detecte algo que hayamos pasado por alto, alguna ocurrencia de manejo “incluso como debe ser” que se nos olvido validar, todos sin excepcion, hemos corregido cosas que nos ha avisado algun cliente, no solo errores, sino cosas que funcionamente no dan error a nivel de codigo pero si a nivel de salida/respuesta de los datos. Uno de mis programas mas recientes, calcula la edad en base a la fecha (antes no lo hacia), pero miraba el anio y el mes pero no el dia, haciendo que la persona por ejemplo se indicara como edad 33 cuando aun tenia 32, algo que ya esta corregido y fue detectado por el usuario que lo usa, mas no por mi en su momento.

Como habia comentado anteriormente, algunos developer tambien identifican la version del paquete bajo un nombre, por ejemplo 2.6.1+lenny5 y 2.6.1+hardy5 siendo Lenny para Debian y Hardy para Ubuntu y mas nomenclaturas para estos u otras distribuciones GNU/Linux identifica al paquete y a que sistema va dirigido/desarrollado (empaquetado).

De todo esto, esta la siguiente pregunta… el como saber cuando a un software le toca ascender de version y que tanto, como saber que estando en la v1.2 la siguiente sera v1.3 o inmediatamente 2.0, conocer el significado de la numeracion (v2.8.3 -> xx.yy.zz) ofrece una idea mas amplia que una unica palabra como Beta o nombresoftware version Gold.

Para tener la opinion de desarrolladores de grandes proyectos, decidi pasar por los canalres IRC de #canaima, irc sobre el desarrollo de la distribucion GNU/Linux Venezolana de nombre “Canaima” donde hable con j0n4th4N y el irc #kumbiaphp (Framework para PHP) donde converse con joanhey uno de sus desarrolladores.

Que significa exactamente la numeracion de una version de software version xx.yy.zz (algunos proyectos incluso tienen mas de 3 secciones de numeraciones). La primera “xx” se incrementa cuando es un nuevo paquete, si las modificaciones de la version del software es alta, un software de v1.0 podria saltar a v2.0 sin problemas. La segunda “yy” se incrementa cuando se agregan nuevas caracteristicas, y la tercera “zz” es referente a correcion de errores.

El significado de estos tres pares en la numeracion de un software o paquete es aceptable, se considera que es correcto. Luego caigo en saber -exactamente- cuando saber, cuanto va a subir la numeracion (creo que nunca ha pasado que disminuya) al menos yo jamas lo he visto. Como saber que de la v1.0 vendria la v1.5 o v2.1 (viendo aqui que nos hemos saltado varias numeraciones). Las versiones no siempre pasan a la siguiente numeracion consecutiva, vemos que pueden saltar inmediatamente a otra numeracion posterior mas alta.

Pensar que por ejemplo que decir la v3.5.37 seria 3 nuevos paquetes, 5 nuevas caracteristicas y 37 errores corregidos, podria no ser realmente cierto, porque en un software (sobre todo de gran tamanio, un proyecto grande de desarrollo) podrian corregirse 230 errores, pero no por eso la version sera v3.5.230, como pensar que 53 nuevas caracteristicas no indica que el paquete tendra como numeracion v3.53.230 y todavia quedaria ver exactamente que entendemos como “nuevos paquetes”, esto no es una numeracion decimal que redondea del 0 al 9 para subir al siguiente numero la numeracion que se antepone a esta.

Se considera que realmente no hay una regla que determine exactamente cual es la siguiente numeracion; como esta numeracion la inicia y la evoluciona una persona o un grupo de personas (desarrolladores) ya que no creo que exista una formula matematica que sea la que lo determine -que de haber, por favor que se me indique en un comentario- el incremento de estas numeraciones basado en el significado de cada una, podria incrementarse -al ojo- del desarrollador.  No es que el programador parado en su v1.0 piense que ahora sera v5.0 solo por gusto, algunos desarrolladores consideran que una version de su software v0.4.37 que luego paso a v0.5 ya podia ser v1.0 estando aun en v0.4.37, asi lo indico joanhey al ejemplificarse en kumbiaphp-framework, del cual el es desarrollador.

Tambien tenemos el tema de que las versiones impares son las de desarrollo (no terminadas) y las versiones pares son las estables (ya probadas).

Sobre que tan evolucionado esta un software o un paquete que lo complementa, es una tematica interesante que podria profundiarse un poco mas, con la ayuda de quien desee dar su comentario para confirmar o corregir este tema que he expuesto, ya que ayudaria a enriquecerlo y depurarlo para que lo que quede, dar por asentado que es asi.


About this entry