Hace tiempo escribí sobre lo ridículo y sin sentido que resultaba el enfoque se algunas organizaciones y desarrolladores (creo que motivados por las llamadas «metodologías ágiles» y la urgencia de entregar cosas en lo que pareciera un proyecto sin final) adoptaban sobre la identificación de las versiones de sus productos. Algo que empecé a notar con Firefox. No ahondaré más en mis razones por las que considero carece de sentido y diluye el propósito del «versionamiento» identificar como una «nueva versión» a algo que no ofrece mayor distinción sobre la anterior (más que quizás un cambio menor o la corrección de algún problema). Mientras que se espera un aumento de capacidad o funcionalidad cuando se nos ofrecen «una nueva versión» (así como el retiro, cambio o adecuación de aquellas menos útiles o problemáticas), un diferente «look and feel» siembre es bienvenido para acentuar la novedad y el cambio. Una «nueva versión» que no ofrezca esto, ¿realmente es una nueva versión?
Pero, ¿qué es una «versión»? La definición en español de este término, curiosamente no sirve para el caso. La definición que el Cambridge Dictionary provee es mucho más ad hoc:
A particular form of something that is slightly different from other forms of the same thing.
Esta «forma particular en que algo que es ligeramente diferente de otras formas de la misma cosa» nos dice que hay un elemento de distinción percibible entre dos objetos que son de alguna forma identificados como semejantes o de una misma categoría. Pero, ¿qué tanto es tantito?
Aunque en el mundo del software estos cambios esperaríamos se dieran con más frecuencia que en el mundo físico, lo cierto es que pueden ser igual de tardíos. Me refiero a que mientras que año con año se presentan nuevos modelos de una misma línea automotriz, un sistema operativo puede darse cada dos o más. Como sea, para el caso del software, la identificación de los cambios está bien reglamentada a través de lo que se conoce como semantic versioning.
Si bien las reglas son claras en cuanto al uso del sistema de numeración, sólo se indica que «[t]he way in which the version number is incremented after this release is dependent on this public API and how it changes» (la especificación habla de API pero interprétese esto como producto). De las reglas se puede inferir hasta cierto punto, cuándo el número mayor (y principal) de versión debe incrementarse y a lo largo de éstas puede leerse cómo aquello que no puede ser reglamentado y formalizado queda en el profesionalismo y responsabilidad del desarrollador.
Cambios de naturaleza estética o de funcionalidad para la «experiencia del usuario» podrán parecer los más difíciles de formalizar como para aplicar estas reglas pero creo que es todo lo contrario. Un cambio en la estética de la interfaz de usuario (que es lo que muchas veces más se vende)— y entendiendo que este cambio no es sólo en colores o posiciones de objetos de ésta —debe obligar a un cambio de número mayor de versión. Aún cuando la funcionalidad del software es la misma, es lo que el usuario final percibe y por lo que distinguirá una versión de otra (regresando al símil automotriz, aun cuando el auto sea el mismo en sus interiores y bajo el capó, si la carrocería es diferente a la del año previo para el consumidor será un auto diferente).
Así que, creo que podemos concluir que, en términos del número mayor de versión, se trata de un punto de percepción. Cuando podemos diferenciar de inmediato algo de alguna otra versión podremos decir que se trata de algo distinto, que merece ser diferenciado. Cuando debemos buscar esas diferencias, se trata de una versión cuyos número menores (después del punto) son los únicos que deben ser cambiados.
¿Me explico?
Dr. Edu 