055.2 Lección 1

La estabilidad es una característica clave que los usuarios esperan del software. La primera pregunta que muchos hacen al enterarse de una nueva versión es: “¿Qué tan estable es?”. En otras palabras, ¿Funcionará de manera confiable o fallará, dañará los datos o producirá resultados incorrectos?

La estabilidad se puede medir en un espectro y muchas personas están felices de utilizar el software incluso cuando todavía hay algunos errores. Pero los equipos de desarrollo tienden a mantener las cosas simples y hablan de forma binaria sobre versiones estable e inestable.

La estabilidad se refiere tanto a los errores del software como a su probabilidad de cambiar de manera visible para los externos. Los desarrolladores podrían considerar inestable una versión de una biblioteca de software porque han cambiado las funciones que llaman los programadores (es decir, porque es posible que los programadores tengan que reescribir su software para la próxima versión). O el software puede ser inestable desde el punto de vista del usuario porque los desarrolladores han eliminado una función.

¿Hay alguna razón para lanzar una versión inestable? Sí: son valiosos para permitir a los usuarios probar nuevas funciones al principio del proyecto y detectar errores.

La mayoría de los proyectos lanzan revisiones muy tempranas de software para que las prueben los clientes clave; estas se denominan versiones alfa. Nadie debería utilizar estas versiones para un trabajo real; son sólo para pruebas. De hecho, los evaluadores deberían ejecutar las versiones alfa en computadoras que no estén realizando ningún trabajo importante, porque los errores en esas versiones podrían dañar los datos almacenados en la computadora.

Cuando el software está cerca de considerarse estable, el proyecto generalmente lanza otra revisión de prueba llamada versión beta. Estos aún no deben usarse para trabajos de producción, sólo para pruebas.

Tanto para las versiones alfa como para las beta, los desarrolladores tienen un proceso para informar errores y realizar un seguimiento del progreso hacia la corrección de estos.

Algunos proyectos incluyen otra etapa entre las versiones beta y estable, cuando los desarrolladores han corregido todos los errores que pueden y piensan que el producto está listo. Llaman a la versión candidato de lanzamiento y se la muestran a clientes o partes interesadas clave para que estas partes interesadas puedan planificar cómo utilizar las nuevas funciones.

Finalmente, algunos proyectos incluyen características que no son del todo estables, porque los usuarios importantes las han solicitado. Los desarrolladores tienen la intención de que los usuarios prueben estas funciones y digan si les gustan, antes de finalizar las interfaces e invertir el esfuerzo para estabilizar las funciones.

La mayoría de los proyectos buscan compatibilidad con versiones anteriores, lo que significa que intentan no eliminar características o funciones que existían en versiones anteriores. La compatibilidad puede existir en varios niveles. Por ejemplo, si los desarrolladores mantienen la compatibilidad con versiones anteriores de la interfaz de programación de aplicaciones (API), prometen que el código fuente antiguo puede seguir funcionando, pero es posible que sea necesario volver a compilarlo. Si los proveedores de hardware o los desarrolladores de sistemas operativos mantienen la compatibilidad con versiones anteriores de la interfaz binaria de la aplicación (ABI), prometen que, los archivos ejecutables antiguos pueden ejecutarse en nuevas versiones del hardware.

Más adelante veremos las formas en que los proyectos manejan la falta de compatibilidad con versiones anteriores, cuando deciden que la interfaz antigua realmente no funciona para las nuevas características o entornos que necesitan soportar.

Idealmente, el software mejoraría cada vez más a medida que los desarrolladores descubran y solucionen sus problemas. Pero con el tiempo, las funciones pueden dejar de funcionar debido a cambios en el entorno del software. Además, se descubren nuevos errores que antes estaban ocultos.

Las nuevas versiones suelen combinar seguridad y corrección de errores con nuevas funciones. Es posible que no desee las nuevas funciones (de hecho, es posible que prefiera alguna función antigua que los desarrolladores eliminaron para dar paso a otras nuevas), pero las personas generalmente actualizan a la nueva versión para obtener las correcciones de seguridad que los protegerán contra ataques de malware.

Algunas personas siguen usando versiones antiguas de software y se niegan a actualizarlas. Normalmente, esto se debe a que la nueva versión rompe algo que funcionaba en su entorno. Cuando las empresas cobran dinero por las actualizaciones, algunos clientes se niegan a actualizar porque no quieren pagar dinero extra, pero pagar por las actualizaciones es poco común en el código abierto.

Los desarrolladores se adaptan a los usuarios de versiones antiguas, si es posible, corrigiendo errores en las versiones antiguas sin agregar características que rompan el software. Naturalmente, los desarrolladores no pueden hacer esto para siempre porque consume tiempo y energía del nuevo trabajo. Llegará un momento en el que se negarán a reparar una versión antigua y les dirán a los usuarios que actualicen o que hagan sus propias correcciones.

La reparación de errores y fallas de seguridad se denomina soporte para el software. Esto es diferente del soporte que ofrecen los servicios de asistencia técnica y otras personas que guían a los usuarios para que comprendan el software. En lo que respecta a la gestión de versiones, una versión compatible es aquella en la que los desarrolladores prometen corregir errores, mientras que una versión no compatible es aquella en la que no lo hacen.

Tenga en cuenta que la noción de “soporte” se aplica principalmente al software creado por empresas u grandes organizaciones. Los proyectos de código abierto más pequeños, que dependen en gran medida de voluntarios, a menudo prometen simplemente hacer lo mejor que puedan para corregir errores y publicar nuevas versiones. No ven la necesidad de arreglar las versiones antiguas. Debido a que el código es abierto, por ende los usuarios que no quieran actualizar pueden pagarle a alguien para que arregle una versión anterior.

Cuando existe soporte, los desarrolladores publican un cronograma que indica durante cuánto tiempo brindarán soporte para cada versión. La fecha en la que finaliza el soporte se denomina fin de vida útil (EOL) del software. Los usuarios pueden mantener la versión anterior hasta el EOL y esperar que se solucionen los errores, pero después del EOL tienen que actualizar o arriesgarse.

Los proyectos importantes, como la distribución Debian de GNU/Linux, ofrecen versiones de soporte a largo plazo (LTS). Eso simplemente significa que los desarrolladores seguirán corrigiendo errores durante un cierto número de años. Los clientes que valoran mucho la estabilidad pueden tener miedo de instalar versiones de software que tengan muchos cambios, en caso de que los cambios rompan los procesos en los que confían los clientes. A estos clientes, en particular a las grandes instituciones, les gusta la seguridad de las versiones LTS.

Los desarrolladores intentan establecer, con mucha antelación, qué cambios quieren hacer en un producto. En las empresas comerciales, hablan con gente de marketing, quienes filtran y resumen lo que les dicen sus clientes. Los proyectos de código abierto dependen más de las ideas enviadas por los desarrolladores y usuarios, que se capturan en una base de datos llamada rastreador de problemas. Si necesita corregir un error o desea una nueva función, complete un problema. Luego, los desarrolladores priorizan los cambios y deciden quién se encargará de cada uno.

Entonces, ¿cómo se eligen y priorizan los cambios? Puede ser un proceso complicado. Pero los buenos directores de proyectos en proyectos de código abierto fomentan una amplia aportación y al mismo tiempo garantizan que se tomen decisiones. Algunos proyectos incluso celebran conferencias en las que los participantes debaten las prioridades.

Una hoja de ruta publicada establece los planes resultantes para mejoras y cambios. Puede extender muchos lanzamientos y muchos años en el futuro. Cada paso se denomina hito y puede o no estar asociado con una fecha objetivo.

Hay dos formas básicas de programar lanzamientos: según el tiempo y las funciones. Un proyecto puede prometer un lanzamiento a intervalos regulares (cada seis meses, por ejemplo) e incluir todo lo que esté terminado en ese momento. Alternativamente, el proyecto puede prometer incluir ciertas funciones en una versión y dejar que los desarrolladores se tomen el tiempo necesario para finalizar esas funciones.

A medida que se acerca el momento del lanzamiento, el administrador de lanzamientos determina las fechas para las versiones alfa, beta y estable. Los miembros del equipo revisan periódicamente los informes de errores e intentan planificar su trabajo para cumplir con estos hitos.

Para finalizar un lanzamiento, un proyecto debe dejar de aceptar ideas para nuevas funciones y centrarse en hacer que las funciones existentes funcionen correctamente. Este momento se llama congelación de funciones.