Hace unos días tuvimos en mi trabajo un detalle un poco fuera de lo común, resulta que nuestro manejo y control de versiones en el estándar actual generaba datos que nadie entendía y que además causó problemas por la longitud de la misma:
Super-XYZ V0R0M0BD 1.0.1.12_1
Dicha nomenclatura estaba compuesta de nombre de la aplicación, Versión, Release,Modificación, y Beta con otro montón de números.. antes de seguir, permitanme lavarme las manos, yo no era parte del proyecto cuando dicho «estándar» se definió 🙂
Sin embargo, la historia no termina ahí, ya siendo parte del equipo de desarrollo, empezamos a tener «microversiones» y entonces teníamos algo así como:
Super-XYZ V0R0M0BD 1.0.1.12V15RC4
Naturalmente, los usuarios que solo veían que cambiaba el «12V algo», comenzaron a ignorar el resto de la nomenclatura y utilizar solo los 2 últimos valores como si de la versión mayor se tratara, tanto en correos electrónicos, charlas entre ellos, y hasta para reportar bugs o incluso en presentaciones oficiales.
El problema aún no era problema hasta que decidieron incluir la información de la versión de la aplicación en reportes generados por la misma, en un espacio no mayor a 10 caracteres… entonces todos se dieron cuenta de lo peculiar y poco útil que resultaba el estándar aplicado después de 6 meses de operaciones en producción 0.o.
Fue así como entonces se decidió cambiar el estándar, y el cual es el punto principal de éste post: necesitabamos un estándar claro, corto, útil para quienes prueban la aplicación en producción y al mismo tiempo permitir al equipo de desarrollo mantener el control de lo que se estaba haciendo entre versiones.
La solución fue de lo mas indignante, humillante e irónicamente posible: usar la nomenclatura propia de Microsoft.
La nomenclatura del número de versión que define Microsoft se compone de 4 partes con amplio sentido común, al menos para mí:
<Major>.<Minor>.<Build>.<Revision>
De acuerdo a la documentación oficial http://msdn.microsoft.com/en-us/library/hdxyt63s
- Major: los ensamblados que tengan el mismo nombre pero diferentes versiones principales no son intercambiables. Un número de versión más alto puede indicar la reescritura principal de un producto en el que no se puede asumir la compatibilidad con los anteriores.
- Minor: si el nombre y el número de versión principal de dos ensamblados son iguales, pero el número de versión secundaria es diferente, esto significa que se ha producido una mejora importante en lo que se refiere a la intención de compatibilidad con los anteriores. Este número de versión secundaria más alto podría indicar una versión de punto de un producto o una nueva versión totalmente compatible con versiones anteriores de un producto.
- Build: una diferencia en el número de Build representa una recompilación del mismo código fuente. Se pueden utilizar números de Build diferentes cuando cambia el procesador, la plataforma o el compilador.
- Revision: los ensamblados con el mismo nombre e iguales números de versión principal y secundaria pero con revisiones diferentes están pensados para ser completamente intercambiables. Un número de revisión más alto se puede usar en una compilación que resuelve una vulnerabilidad de seguridad en un ensamblado de una versión anterior.
No obstante, nosotros decidimos invertir el valor de build y Revision, cuidando de no afectar la forma en como el Runtime determina cual es la versión mas reciente cuando compara ensamblados:
<Major>.<Minor>.<Revision>.<Build>
De esta manera, el valor de Build solo se incrementa dentro de la versión en desarrollo, y cuando se libera a producción, se reinicia en cero y en cambio, se incrementa el valor Revision. Realmente es una tontería, pero como pueden ver, también es de las cosas que suelen pasar jeje.
Al final, nuestro «nuevo» y flamante estándar luce así:
Super-XYZ 1.12.16.0
Mucho mejor, ¿no les parece? 😉
El Código del Lenguaje 