Tabla de contenidos
Este cap�tulo trata sobre c�mo los proyectos de software libre empaquetan y liberan su software, y c�mo los patrones de desarrollo generales se organizan en torno a esos objetivos.
Una de las mayores diferencias entre los proyectos de c�digo abierto y los propietarios es la falta de control centralizado sobre el equipo de desarrollo. Cuando una nueva versi�n est� siendo preparada, esta diferencia es especialmente notable: una empresa puede orientar a todo el equipo de desarrollo a centrarse �nicamente en la futura versi�n, dejando de lado nuevos desarrollos futuros y la soluci�n de bugs no cr�ticos hasta que la versi�n sea liberada. Los grupos de voluntarios no son tan monol�ticos. La gente participa en los proyectos por todo tipo de razones, y aquellos que no est�n interesados en ayudar con una versi�n dada todav�a querr�n continuar con su trabajo regular de desarrollo mientras la versi�n se est� realizando. Dado a que el desarrollo nunca finaliza, el proceso de liberaci�n de versiones del Open Source tiende a alargarse, pero es menos disruptivo, que el proceso de liberaci�n del software comercial. Es algo similar a la reparaci�n de una larga carretera. Hay dos maneras de reparar una carretera: puedes cerrarla completamente, para que un equipo de reparaciones pueda estar completamente sobre ella hasta que el problema se solucione, o puedes trabajar en un par de carriles a un tiempo, mientras dejas los otros abiertos al tr�fico. La primera forma es m�s eficiente para el equipo de reparaci�n , pero para nadie m�s—la carretera est� completamente cerrada hasta que finalice el trabajo. La segunda manera supone m�s tiempo y problemas para el equipo de reparaciones (ahora ellos tendr�n que trabajar con menos gente y menos equipamiento, en apretadas condiciones, con auxiliares para frenar y dirigir el tr�fico, etc.), pero al menos la carretera permanece abierta, aunque no sea con la capacidad total.
Los proyectos de c�digo abierto tienden a trabajar de la segunda manera. De hecho, para una pieza madura de software con diversas l�neas de versiones diferentes siendo mantenidas simult�neamente, el proyecto est� en una especie de estado permanente de reparaciones menores de la carretera. Hay siempre un par de carriles cerrados; el grupo de desarrollo en general siempre tolera un nivel de inconvenientes de fondo constante pero bajo, para que las liberaciones se hagan bajo una planificaci�n regular.
El modelo que posibilita esto se generaliza a algo m�s que s�lo la liberaci�n de versiones. Es el principio de paralelizaci�n de tareas que no son interdependientes —un principio que de ning�n modo es exclusivo del desarrollo de software de c�digo abierto, por supuesto, pero los proyectos de c�digo abierto lo implementan de una manera particular. No pueden darse el lujo de molestar demasiado al personal de la carretera ni al tr�fico regular, pero tampoco pueden permitirse que haya personas dedicadas a pararse junto a los conos de color naranja y controlar el tr�fico. Por lo tanto, gravitan en torno a procesos que tienen niveles planos y constantes de esfuerzo de administraci�n, en lugar de altos y bajos. Los desarrolladores generalmente est�n dispuestos a trabajar con cantidades peque�as pero consistentes de inconvenientes; la predicibilidad les permite ir y venir sin preocuparse acerca de si sus planificaciones entran en conflicto con lo que ocurre en el proyecto. Pero si el proyecto estuviera sujeto a una planificaci�n maestra en la cual unas actividades excluyen a otras, el resultado ser�a que muchos desarrolladores permanecer�an inactivos la mayor parte del tiempo — que ser�a, no s�lo ineficiente, sino aburrido, y por tanto peligroso, ya que un desarrollador aburrido est� cerca de convertirse en un ex-desarrollador.
El trabajo de liberaci�n de versiones suele ser la tarea de no-desarrollo m�s perceptible que ocurre en paralelo con el desarrollo, por lo que los m�todos descritos en las siguientes secciones est�n orientados principalmente a habilitar las liberaciones. Sin embargo, nota que esto tambi�n aplica a otras tareas paralelizables, tales como traducciones e internacionalizaciones, amplios cambios en la API realizados gradualmente en todo el c�digo base, etc.
Antes de que hablemos de c�mo liberar una versi�n, echemos un vistazo a c�mo nombrar el lanzamiento, lo cual requiere saber qu� significan en realidad para los usuarios las versiones liberadas. Una versi�n liberada significa que:
Algunos errores viejos han sido corregidos. Esta es probablemente la �nica cosa en la que los usuarios pueden contar como verdadera de cada versi�n.
Se han a�adido nuevos errores. Por lo general, tambi�n se puede contar con esto, excepto a veces en el caso de lanzamientos de seguridad u otros eventos �nicos (ver “Security Releases” m�s adelante en este cap�tulo).
Nuevas caracter�sticas pueden haber sido agregadas.
Nuevas opciones de configuraci�n pueden haber sido agregadas, o el significado de viejas opciones puede haber sido cambiado sutilmente. Tambi�n pueden haber cambiado los procedimientos de instalaci�n desde la �ltima liberaci�n, aunque uno siempre espera que no.
Es posible que se hayan introducido cambios incompatibles, por ejemplo, que los formatos de datos utilizados por versiones anteriores del software ya no se puedan utilizar sin someterse a alg�n tipo de instancia de conversi�n unidireccional (posiblemente manual).
Como puedes ver, no todas estas cosas son buenas. Esta es la raz�n por la que los usuarios experimentados se aproximan a las nuevas versiones liberadas con cierta inquietud, especialmente cuando el software es maduro y ya estaba en su mayor�a haciendo lo que quer�an (o pensaban que quer�an). Incluso la llegada de nuevas funciones es una bendici�n mixta, ya que puede significar que el software ahora se comportar� de formas inesperadas.
El prop�sito de la numeraci�n de las versiones liberadas, por lo tanto, es doble: obviamente, los n�meros deben comunicar sin ambig�edad el orden de las versiones dentro de una serie dada (es decir, al mirar los n�meros de cualquiera de las dos versiones en la misma serie, uno puede saber cu�l vino m�s adelante), pero tambi�n deben indicar de la manera m�s compacta posible el grado y la naturaleza de los cambios en cada versi�n.
�Todo eso en un n�mero? Bueno, m�s o menos, s�. Las estrategias de numeraci�n de versiones liberadas son de las discusiones m�s antiguas (ver “Cuanto m�s blando sea el tema, m�s largo ser� el debate” en Cap�tulo�6, Comunicaciones), y es improbable que en el futuro cercano se establezca un solo estandard en el mundo. Sin embargo, han surgido algunas buenas estrategias, junto con un principio universalmente aceptado: ser consistente. Seleccionar un esquema de numeraci�n, documentarlo, y apegarse a �l. Tus usuarios te lo agradecer�n.
Esta secci�n describe en detalle las convenciones habituales de numeraci�n de lanzamientos y supone muy poco conocimiento previo. Su prop�sito es principalmente como referencia. Si ya est�s familiarizado con estas convenciones, puedes omitir esta secci�n.
Los n�meros de versi�n liberada son grupos de d�gitos separados por puntos:
Scanley�2.3
Singer�5.11.4
...etc�tera. Los puntos no son puntos decimales, son solo separadores; "5.3.9" ser�a seguido por "5.3.10". Ocasionalmente algunos proyectos insinuan otro significado, el m�s famoso es el kernel de Linux con su secuencia "0.95", "0.96"... "0.99" que conduce a Linux 1.0, pero la convenci�n de que los puntos no son decimales est� firmemente establecida y deber�a ser considerada como est�ndar. No hay l�mite en el n�mero de componentes (porciones de d�gitos que no contienen puntos), pero la mayor�a de los proyectos no van mas all� de tres o cuatro. Las razones de por qu� se aclarar�n m�s adelante.
Adicionalmente a los componentes num�ricos, algunas veces los proyectos agregan una etiqueta descriptiva como "Alfa" o "Beta" (ver Alfa y Beta), por ejemplo:
Scanley�2.3.0�(Alfa)
Singer�5.11.4�(Beta)
Un clasificador como Alfa o Beta significa que esta versi�n liberada precede a una versi�n de futura liberaci�n que va a tener el mismo n�mero sin el clasificador. As�, "2.3.0�(Alfa)" conduce eventualmente a "2.3.0". Con el fin de permitir varias versiones candidatas de una sola vez, los clasificadores en s� mismos pueden tener meta-clasificadores. Por ejemplo, aqu� una serie de versiones en el orden en el que estar�n disponibles al p�blico:
Scanley�2.3.0�(Alfa�1)
Scanley�2.3.0�(Alfa�2)
Scanley�2.3.0�(Beta�1)
Scanley�2.3.0�(Beta�2)
Scanley�2.3.0�(Beta�3)
Scanley�2.3.0
Observa que cuando tiene el calificador "Alfa", Scanley "2.3" se escribe como "2.3.0". Los dos n�meros son equivalentes —los componentes finales con cero siempre pueden eliminarse por brevedad, pero cuando hay un calificador presente, la brevedad est� fuera de alcance de todos modos, por lo que uno podr�a optar por la exhaustividad.
Otros calificadores en uso semi-regular incluyen "Estable", "Inestable", "Desarrollo" y "RC" (para "Versi�n candidata"). Los m�s utilizados siguen siendo "Alfa" y "Beta", con "RC" en un tercer lugar cercano, pero ten en cuenta que "RC" siempre incluye un meta-calificador num�rico. Es decir, no liberas "Scanley�2.3.0�(RC)", liberas "Scanley�2.3.0�(RC�1)", seguido de RC2, etc.
Esas tres etiquetas, "Alfa", "Beta" y "RC", son bastante conocidas ahora, y no recomiendo usar ninguna de las otras, aunque las otras a primera vista parezcan mejores opciones porque son palabras normales, no jerga. Pero las personas que instalan software desde versiones liberadas ya est�n familiarizadas con las tres grandes, y no hay raz�n para hacer las cosas de manera gratuita diferente a la forma en que todos los dem�s las hacen.
Aunque los puntos en los n�meros de lanzamiento no son puntos decimales, s� indican la importancia del valor de posici�n. Todos los lanzamientos "0.X.Y" preceden a "1.0" (que es equivalente a "1.0.0", por supuesto). "3.14.158" precede inmediatamente a "3.14.159", y precede no inmediatamente a "3.14.160" as� como a "3.15.cualquier cosa", y as�.
Una pol�tica de numeraci�n de versiones liberadas consistente le permite al usuario mirar dos n�meros de versi�n para la misma pieza de software y decir, solo a partir de los n�meros, las diferencias importantes entre las mismas. En un sistema t�pico de tres componentes, el primer componente es el n�mero principal�, el segundo es el n�mero menor�, y el tercero es el n�mero micro� (a veces tambi�n se le llama n�mero "parche"). Por ejemplo, la versi�n liberada "2.10.17" es la decimoctava versi�n liberada micro (o versi�n liberada de parche) en la und�cima l�nea de versiones liberadas menores dentro de la segunda serie de versiones liberadas principales. Las palabras "l�nea" y "serie" se usan informalmente aqu�, pero significan lo que uno esperar�a: una serie principal es simplemente todas las versiones liberadas que comparten el mismo n�mero principal, y una serie menor (o l�nea menor) consiste en todos las versiones liberadas que comparten el mismo n�mero menor y n�mero principal. Es decir, "2.4.0" y "3.4.1" no est�n en la misma serie menor, a pesar de que ambas tienen "4" para su n�mero menor; por otro lado, "2.4.0" y "2.4.2" est�n en la misma l�nea menor, aunque no son adyacentes si se liber� "2.4.1" entre ellas.
Los significados de estos n�meros son exactamente lo que cabr�a esperar: un incremento del n�mero principal indica que se produjeron cambios importantes; un incremento del n�mero menor indica cambios menores; y un incremento del n�mero micro indica cambios realmente triviales. Algunos proyectos agregan un cuarto componente, generalmente llamado n�mero de parche,� para un control especialmente espec�fico sobre las diferencias entre sus versiones liberadas (confusamente, otros proyectos usan "parche" como sin�nimo de "micro" en un sistema de tres componentes). Tambi�n hay proyectos que utilizan el �ltimo componente como un n�mero de compilaci�n�, que se incrementa cada vez que se construye el software y que no representa ning�n cambio m�s que esa compilaci�n. Esto ayuda al proyecto a vincular cada informe de error con una compilaci�n espec�fica, y es probablemente m�s �til cuando los paquetes binarios son el m�todo predeterminado de distribuci�n.
Aunque existen muchas convenciones diferentes sobre cu�ntos componentes usar y qu� significan los componentes, las diferencias tienden a ser menores —se obtiene un poco de margen de maniobra, pero no mucho. Las siguientes dos secciones discuten algunas de las convenciones m�s utilizadas.
La mayor�a de los proyectos tienen reglas sobre qu� tipo de cambios se permiten en una versi�n liberada si una solo incrementa el n�mero micro, diferentes reglas para el n�mero menor y a�n diferentes para el n�mero principal. Todav�a no hay un est�ndar establecido para estas reglas, pero aqu� describir� una pol�tica que ha sido utilizada con �xito por varios proyectos. Es posible que desees simplemente adoptar esta pol�tica en tu propio proyecto, pero incluso si no lo haces, sigue siendo un buen ejemplo del tipo de informaci�n que los n�meros de versi�n liberada deben transmitir. Esta pol�tica est� adaptada del sistema de numeraci�n utilizado por el proyecto APR, ver http://apr.apache.org/versioning.html.
Los cambios solo en el n�mero micro (es decir, los cambios dentro de la misma l�nea menor) deben ser compatibles con versiones anteriores y posteriores. Es decir, los cambios deben ser solo correcciones de errores o mejoras muy peque�as en las caracter�sticas existentes. Las nuevas caracter�sticas no deben introducirse en una versi�n micro.
Los cambios en el n�mero menor (es decir, dentro de la misma l�nea principal) deben ser compatibles con versiones anteriores, pero no necesariamente compatibles con versiones posteriores. Es normal que se introduzcan nuevas funciones en una versi�n menor, pero generalmente no hay demasiadas funciones nuevas a la vez.
Cambios en el n�mero principal marcan l�mites de compatibilidad. Una nueva versi�n principal puede ser incompatible con versiones anteriores y posteriores. Se espera que una versi�n importante tenga nuevas caracter�sticas, e incluso puede tener conjuntos de caracter�sticas completamente nuevos.
Lo que significa exactamente compatible con versiones anteriores y compatible con versiones posteriores depende de lo que haga tu software, pero en contexto generalmente no est�n abiertos a mucha interpretaci�n. Por ejemplo, si tu proyecto es una aplicaci�n cliente/servidor, entonces "compatible con versiones anteriores" significa que actualizar el servidor a 2.6.0 no deber�a hacer que ning�n cliente 2.5.4 existente pierda la funcionalidad o se comporte de manera diferente a como lo hac�a antes (a excepci�n de bugs que fueron arreglados, por supuesto). Por otro lado, la actualizaci�n de uno de esos clientes a 2.6.0, junto con el servidor, podr�a hacer que la nueva funcionalidad est� disponible para ese cliente, funcionalidad que los clientes de la versi�n 2.5.4 no saben c�mo aprovechar. Si eso sucede, entonces la actualizaci�n no es "compatible con versiones posteriores": claramente no se puede volver a la versi�n 2.5.4 de ese cliente y mantener toda la funcionalidad que ten�a en 2.6.0, ya que parte de esa funcionalidad era nueva en 2.6.0.
Esta es la raz�n por la que las versiones liberadas micro son esencialmente solo para corregir errores. Deben seguir siendo compatibles en ambas direcciones: si actualiza de 2.5.3 a 2.5.4, luego cambia de idea y baja de nuevo a 2.5.3, no se debe perder ninguna funcionalidad. Por supuesto, los errores corregidos en 2.5.4 reaparecer�an despu�s de volver hacia atr�s, pero no perder�a ninguna caracter�stica, excepto en la medida en que los errores restaurados impidan el uso de algunas caracter�sticas existentes.
Los protocolos cliente/servidor son solo uno de los muchos dominios de compatibilidad posibles. Otro es el formato de datos: �el software escribe datos en un almacenamiento permanente? Si es as�, los formatos que lee y escribe deben seguir las pautas de compatibilidad prometidas por la pol�tica de n�mero de versi�n. La versi�n 2.6.0 debe poder leer los archivos escritos por 2.5.4, pero puede actualizar el formato de manera silenciosa a algo que 2.5.4 no pueda leer, porque no se requiere la capacidad de volver atr�s en la versi�n a trav�s de un l�mite de n�mero menor. Si tu proyecto distribuye librer�as de c�digos para que otros programas las utilicen, entonces las API tambi�n son un dominio de compatibilidad: debes asegurarte de que las reglas de compatibilidad de fuente y de binario est�n detalladas de tal manera que el usuario informado nunca deba preguntarse si es seguro o no actualizar. Ella podr� mirar los n�meros y saberlo al instante.
En este sistema, no tienes la oportunidad de comenzar de nuevo hasta que incrementas el n�mero principal. A menudo, esto puede ser un verdadero inconveniente: puede haber funciones que deseas agregar, o protocolos que deseas redise�ar, que simplemente no se pueden hacer mientras se mantiene la compatibilidad. No hay una soluci�n m�gica para esto, excepto tratar de dise�ar las cosas de forma extensible en primer lugar (un tema que merece su propio libro, y ciertamente fuera del alcance de este). Sin embargo, la publicaci�n de una pol�tica de compatibilidad de versiones y su cumplimiento son una parte ineludible de la distribuci�n de software. Una sorpresa desagradable puede alienar a muchos usuarios. La pol�tica que acabo de describir es buena en parte porque ya est� bastante extendida, pero tambi�n porque es f�cil de explicar y recordar, incluso para aquellos que a�n no est�n familiarizados con ella.
En general, se entiende que estas reglas no se aplican a las versiones anteriores a la 1.0 (aunque tu pol�tica de versi�n probablemente deber�a declararlo de manera expl�cita, solo para que quede claro). Un proyecto que a�n est� en desarrollo inicial puede liberar 0.1, 0.2, 0.3 y as� sucesivamente en secuencia, hasta que est� listo para 1.0, y las diferencias entre esas versiones liberadas pueden ser arbitrariamente grandes. Los n�meros micro en versiones anteriores a la 1.0 son opcionales. Dependiendo de la naturaleza de tu proyecto y las diferencias entre las versiones liberadas, puede ser �til tener 0.1.0, 0.1.1, etc., o no. Las convenciones para los n�meros de liberaci�n anteriores a la 1.0 son bastante flexibles, principalmente porque la gente entiende que las fuertes restricciones de compatibilidad podr�an obstaculizar demasiado el desarrollo temprano, y porque los primeros usuarios tienden a perdonar de todos modos.
Recuerda que todos estos requerimientos solo se aplican a este sistema particular de tres componentes. Tu proyecto podr�a f�cilmente crear un sistema de tres componentes diferente, o incluso decidir que no necesita una granularidad fina y, en su lugar, utilizar un sistema de dos componentes. Lo importante es decidir con anticipaci�n, publicar exactamente lo que significan los componentes y atenerse a ellos.
Algunos proyectos utilizan la paridad del componente de n�mero menor para indicar la estabilidad del software: par significa estable, impar significa inestable. Esto se aplica solo al n�mero menor, no a los n�meros principales y micro. Los incrementos en el n�mero micro todav�a indican correcciones de errores (no hay nuevas caracter�sticas), y los incrementos en el n�mero principal a�n indican grandes cambios, nuevos conjuntos de caracter�sticas, etc.
La ventaja del sistema par/impar, que ha sido utilizado por el proyecto del kernel de Linux entre otros, es que ofrece una forma de liberar nueva funcionalidad para realizar pruebas sin someter a los usuarios de producci�n a un c�digo potencialmente inestable. La gente puede ver en los n�meros que "2.4.21" se puede instalar en su servidor web en l�nea, pero que "2.5.1" probablemente deber�a limitarse a los experimentos de estaciones de trabajo en el hogar. El equipo de desarrollo maneja los informes de errores que provienen de la serie inestable (n�mero menor impar), y cuando las cosas comienzan a calmarse despu�s de un cierto n�mero de versiones liberadas micro en esa serie, incrementan el n�mero menor (lo que lo hace par), restablece el n�mero micro de nuevo a "0" y libera un paquete presumiblemente estable.
Este sistema conserva, o al menos, no est� en conflicto con las pautas de compatibilidad dadas anteriormente. Simplemente sobrecarga el n�mero menor con alguna informaci�n adicional. Esto obliga a que el n�mero menor se incremente con el doble de frecuencia de lo que ser�a necesario, pero no hay mucho da�o en eso. El sistema par/impar es probablemente mejor para proyectos que tienen ciclos de liberaci�n de versiones muy largos, y que por su naturaleza tienen una alta proporci�n de usuarios conservadores que valoran la estabilidad por encima de las nuevas caracter�sticas. Sin embargo, no es la �nica forma de probar nuevas funcionalidades en la naturaleza. “Stabilizing a Release” m�s adelante en este cap�tulo describe otro m�todo, quiz�s m�s com�n, de liberar al p�blico c�digo potencialmente inestable, marcado para que las personas tengan una idea de las concesiones de riesgo/beneficio inmediatamente al ver el nombre de la liberaci�n.