Ahora que finaliza el año, comienzan a surgir las típicas listas de los 10 desarrollos claves del año, las diez adquisitiones más importantes del año, los diez fracasos más sonados, y así con tantos topics como se nos ocurra. Este año además, finaliza la década. Esto quiere decir que a todas estas listas, habrá que añadir las referidas a los mismos topics, pero a nivel de la década.
Si tuviéramos una lista referida a Java, y en concreto a los JSR (Java Specification Requests), hay uno del que se ha hablado bastante este año: JSR 294. JSR 294 pretende dividir la API Java en módulos. JSR 294 incluiría modificaciones en el lenguaje Java para permitir especificar dependencias entre módulos. Si uno está desarrollando una aplicación que produce logs, la aplicación puede definir una dependencia con el módulo java.logging.
Típicamente, la aplicación, además de indicar que depende de un determinado módulo, necesitará indicar también una versión o conjunto de versiones de ese módulo. Dado que uno puede depender de clases que sólo se incorporaron al módulo a partir de cierta versión, se hace necesario definir cuál es la mínima versión necesaria. Además, de vez en cuando las APIs se rompen por pura evolución (perdiendo la compatibilidad hacia atrás), por lo que lo habitual es que la versión sea realmente un rango de versiones.
En Eclipse, por ejemplo, los diferentes módulos especifican sus dependencias con un identificador de módulo (que debe ser único) y un conjunto de cuatro segmentos que identifican la versión concreta del módulo. Los tres primeros segmentos son numéricos, y se denominan major, minor y service. El último segmento es alfanumérico y se denomina qualifier. Realmente, los tres primeros son los importantes (de hecho las versiones oficiales de Eclipse normalmente sólo exponen estos tres primeros números).
El segmento major indica la versión de la API que contiene el producto. Es de esperar que si nos vasamos en Eclipse 3.x.x nuestro plug-in debería funcionar tanto en Eclipse Ganymede (3.4.x) como en Eclipse Galileo 3.5.x) o incluso en el futurible Eclipse Helios (3.6.x).
El segmento minor indica las características «visibles» presentes en el producto. Este número no se refiere a la API si no a las funcionalidades del producto. Un cambio en el minor segment normalmente significa que se ha modificado/añadido alguna funcionalidad del producto, pero no la API.
El segmento service indica características normalmente no visibles. Con este segmento se suelen identificar por ejemplo cambios debidos a la resolución de bugs en el producto.
El segmento qualifier se utiliza para identificar versiones «nocturnas», de integración, milestones, etc. También se utiliza para dotar a la versión de información como la fecha y hora de construcción del producto.
Y aquí empiezan los problemas. Mientras que en plataformas como Eclipse la especificación de versiones tiene una semántica clara, en el JSR 294 barajan un sistema de versiones que no dota de ninguna semántica a los diferentes segmentos. Sería posible especificar versiones utilizando por ejemplo números binarios (como el título de este post). Este no es un caso aislado, y determinados proyectos software muy conocidos utilizan sistemas de versionado con poca o nula semántica.
Alex Blewitt ha estado escribiendo algunos posts sobre el tema. Son muy divertidos y comenta los fantasiosos sistemas de versionado que podrían crearse atendiendo a la especificación de JSR 294.
Me ha llamado especialmente la atención el sistema basado en los números irracionales. Lo más asombroso de todo es que haya software que utilice efectivamente este sistema. ¿Qué sistema de versionado te gusta más?
CodeUrjc 