Primero hay quienes numeran sus versiones de la forma tradicional, con la 1.0, 1.1, 2.0, etc. Dentro de este esquema, hay muchas formas de utilizarlo. En general, un número de versión alto sugiere un programa maduro, mientras que un número bajo puede sugerir un producto incompleto. Pero conozco proyectos excelentes, que llevan años en desarrollo, llenos de funcionalidades, y que no han llegado todavía ni a la versión 1, como por ejemplo Inkscape, que va por la versión 0.48, y sin embargo todavía no encontré algo que no pueda hacer, y eso que yo solía ser un usuario más o menos avanzado de Corel Draw, allá por las versiones 3, 5 y 7. En el caso de Inkscape, el motivo creo que es simplemente una planificación demasiado ambiciosa; van a usar el 1.0 cuando tengan todo lo que soñaron en esa herramienta y algunas cosas más que se les ocurrieron después también. En otra línea se encuentran proyectos como Firefox, cuyo número de versión avanza de forma ridícula, y en poco más de un año pasamos de la 4 a la 14. El cambio parece haber sido impulsado por las odiosas comparaciones con la competencia. Si Internet Explorer iba a por el 9, Chrome por el 6, Opera alrededor del 11, Mozilla con el 3 parecía poco. Por una cuestión de puro marketing diría, decidieron acelerar la numeración. Algo similar o peor pasó con mi tan preciada distribución de GNU/Linux favorita, Slackware. Slackware quedó atrasada en números respecto a otras distros, y la solución fué más directa: no cambiaron su sistema de numeración ni mucho menos, simplemente dieron un salto en el tiempo y se comieron unos cuanto números pasando directamente desde la 4 a la 7 y luego siguieron como si nada. Jamás hubo una versión 5 o 6.
No me gusta utilizar ese tipo de numeración porque jamás se cuanto saltar. Cuando cambio algo, nunca me decido si la envergadura del cambio justifica una nueva versión (1.0 a 2.0), subversión (1.0 a 1.1), revisión (1.0 a 1.0.1), o qué. En algunos proyectos hay políticas bien claras para eso, como el roadmap de Inkscape o Gimp, entre otros no. En las bibliotecas y otras componentes de software que consumen los programadores, un cambio en el primer número suele significar un cambio grande, de interfaz o de la forma de hacer las cosas, mientras que el segundo alguna mejora que generalmente no afecta la compatibilidad hacia atrás, y el tercero una revisión o corrección de errores mayormente. En muchos casos los números dicen algo más. Por ejemplo, en cuanto al kernel de linux hasta la versión 2.6, y muchos otros proyectos que copiaron la idea, los números pares indicaban versiones estables, mientras que los impares versiones de desarrollo. En Slackware, desde hace poco el segundo número de la versión de la distribución indica la versión del Kernel que utiliza. Así se pueden encontrar varios criterios que ayudan a la decisión.
Una alternativa demasiado simplista sería hacer saltos constantes en la numeración sin importar el tamaño del cambio. Como sería, por ejemplo, el número de revisión en un repositorio svn. Aquí no hay que deliberar tanto, es fácil numerar, es fácil comparar, pero no significa nada. Cuando sale Office 2012 o Corel Draw X4 la gente sabe que hay algo nuevo. Pero en gran parte es porque estas versiones no cambian con frecuencia. Si yo pasara de la revisión 10563 a la 10569 no parecería gran cosa, cuando en realidad podría ser tanto la corrección de algunos errores de tipeo en la ayuda, como la inclusión de toda una nueva funcionalidad, o ambas. Así que si el número no me va a decir mucho acerca del tamaño del cambio, al menos que me diga alguna otra cosa para que sea más fácil interpretarlo.
Entonces la segunda alternativa es mejor, una versión basada en la fecha, eso evita problemas, el número sale del almanaque, no hay que pensarlo. Hablamos de Ubuntu 11.10 y 12.04, significando Octubre de 2011 o Abril de 2012. Eso está muy bien cuando se tiene un cronograma de lanzamientos regulares, en este caso una versión cada 6 meses. Hablamos de Office 2008 u Office 2012, pero eso no me alcanza porque uno no saca una versión por año. Se puede ir a Ayuda->Acerca de y leer la verdadera versión en la letra chica, pero el usuario no lo hace. Y yo quiero que cuando me escriban me digan facil pero claramente que versión tienen, y que sepan si la que está en el sitio es más nueva, etc. Y como a veces saco versiones muy pegadas, con el año y el mes no me alcanza, por eso uso la fecha completa, pero poniendo primero el año, despues el mes, y finalmente el día. De esta forma, el número que se arma es un entero que permite comparar directamente 2 versiones para saber cual es mas nueva sin separarlo, y al ordenar los archivos instaladores por orden alfabético como hace cualquier explorador de archivos ya quedan ordenados por fecha, o también para que el usuario sepa cuan viejo es su programa, o que si le digo "la semana pasada corregí ese error" se de cuenta sin pensar mucho que su versión es más vieja y tiene que actualizar.
Ahora también está de moda usar una doble nomenclatura de números y palabras. Las palabras los hacen más fáciles de recordar y hacen que tenga gancho. Suena mejor Windows XP y Windows Vista, que Windows 5 y Windows 6. Entonces, en Ubuntu por ejemplo, además del número-fecha, cada versión tiene un animal y un adjetivo, que empiezan con la misma letra, y esa letra va avanzando en el orden del abecedario. Los sistemas operativos de Mac usan gatotes en sus nombres. En Fedora por ejemplo, dejaron la última elección al público mediante un sistema de propuestas y votaciones y salió algo como "Spherical Cow" (vaca esférica), que a mí me parece un muy muy buen nombre, pero que para muchos es poco serio (y las otras opciones finalistas también, y por eso hace abrió un debate sobre la continuidad o no de esta metodología).
En resúmen, elegir el sistema de numeración/nomenclatura de versiones no es tan trivial. Darle un significado reconocible a dicho sistema menos. Yo me quedo con las fechas por ahora para evitar esas discusiones y no pensar demasiado, dado que subo muchas versiones al año. Además, como los ciclos de desarrollo no son iguales, no están planificados, diría que ni existen, no puedo agregar mucho más. El único detalle de color que ya habrán notado, es que cuando algo importante o interesante cambia en ZinjaI cambia también algún detalle del splash introduciendo algún elemento que puede estar relacionado al cambio, generalmente en la esquina inferior derecha. Por lo demás, pensé en no pensarlo demasiado.
de compilación en paralelo, el splash mostraba tantos pingüinos como nucleos
tuviese la pc donde corría, igual que el booteo del kernel de Linux.
No hay comentarios:
Publicar un comentario