Gestión de proyectos de software libre (IV). Entrega de paquetes y control de versiones

En esta cuarta entrega de la serie de posts sobre la gestión de software libre (traducción del texto original de Benjamin Mako Hill), “Mako” nos explica cuestiones sobre la entrega de paquetes de software, el tan necesario control de versiones y algunas recomendaciones más sobre la entrega.

Otras cuestiones sobre la entrega

Muchas de las restantes cuestiones alrededor de la creación de un nuevo programa software caen dentro de lo que mucha gente denomina como cuestiones de sentido común. Se ha dicho a menudo que la ingeniería del software es un 90% de sentido común combinado con un 10% de conocimiento especializado. De todos modos, son dignas de mencionar brevemente con la esperanza de que pudiesen hacer recordar algo a un desarrollador que pudiese haber olvidado.

Nombres del paquete.

Estoy de acuerdo con ESR1 cuando dice que: “Es de ayuda para todo el mundo el que todos tus ficheros comprimidos2 tengan nombre tipo GNU – prefijo con todos caracteres alfanuméricos en minúsculas, seguido de un guión, seguido de un número de versión, extensión, y otros sufijos”. Hay más información (incluyendo muchos ejemplos de qué es lo que no hay que hacer en su Software Release Practices HOWTO que está incluida en la bibliografía de este HOWTO y que puede encontrarse en el LDP3.

Formatos del paquete.

Los formatos del paquete puede diferir dependiendo del sistema en el que desarrollas. Para el software basado en windows, los ficheros Zip (.zip) son normalmente el formato elegido. Si desarrollas para GNU/Linux, *BSD, o cualquier UN*X, asegúrate que tu código fuente esté disponible en formato tar y gzip (.tar.gz). La compresión UNIX (.Z) ha pasado tanto de moda como de su utilización y los ordenadores más rápidos han resaltadoel formato bzip2 (.bz2) como un medio de compresión más efectivo. Yo creo todos mis releases disponibles en tarballs tanto en formato gzip como bzip2.

Los paquetes binarios deben ser siempre específicos de una distribución. Si puedes crear paquetes binarios para una versión actual de una distribución importante, harás feliz a tus usuarios. Intenta promover relaciones con usuarios o desarrolladores de grandes distribuciones para desarrollar un sistema coherente de creación de paquetes binarios. A menudo es buena idea proveer RPMs de RedHat (.rpm), deb’s para Debian (.deb) y fuentes RPM SRPM’s si es posible. Recuerda: Aunque los paquetes binarios son buenos, tu prioridad debería ser siempre la de conseguir los fuentes empaquetados y liberados. Tus usuarios o colegas de desarrollo pueden y harán los paquetes binarios para tí.

Sistemas de control de versiones

Un sistema de control de versiones puede hacer que muchos de los problemas de empaquetado (y muchos de otros problemas mencionados en este HOWTO) sean menos problemáticos. Si estás utilizando *NIX, CVS es tu mejor apuesta. Recomiendo de todo corazón el libro de Karl Fogel referente a este tema (y su versión publicada en HTML).

Sea CVS o no, seguramente deberías invertir algo de tiempo aprendiendo sobre un sistema de control de versiones porque provee una forma automatizada de resolver muchos de los problemas descritos en este HOWTO. No conozco ninguna versión libre de sistemas de control de versiones para Windows o Mac OS pero sé que existen clientes CVS para ambas plataformas. Websites como SourceForge hacen un gran trabajo con una interface buena y fácil de utilizar para CVS.

Me hubiese gustado dedicar más espacio para CVS en este HOWTO porque me encanta (¡incluso utilizo CVS para mantener las versiones de este HOWTO!) pero creo que está fuera del alcance de este documento y ya existen sus propios HOWTOs. El más notable es el CVS Best Practices HOWTO [CVSBESTPRACTICES] que he incluido en la bibliografía adjunta.

Golosinas4 prácticas y consejos para la entrega.

Otros consejos útiles son:

  • Comprueba que tu programa puede encontrarse siempre en un único lugar. A menudo esto significa que tienes un único directorio accesible via FTP o la web donde la versión más nueva puede ser reconocida rápidamente. Una técnica efectiva es la de proveer una enlace simbólico llamado “tunombredeproyecto-latest” que esté siempre apuntando al release más reciente o a la versión de desarrollo de tu aplicación software. Ten en cuenta que este lugar recibirá muchas peticiones de descarga de releases por lo que asegúrate que el servidor que elijas tenga el ancho de banda adecuado.

  • Comprueba que tienes una dirección de email coherente para los informes de errores. Normalmente es buena idea al hacer esto que no sea tu dirección primaria de email como tunombredeproyecto@host o tunombredeproyecto-bugs@host. De esta manera, si alguna vez decides transferir el mantenimiento o tu dirección de email cambia, solo tienes que cambiar a dónde redirecciona la dirección email. También permitirá a más de una persona tratar con la llegada de correo si tu proyecto llega a ser tan enorme que esperas que sea.

1Eric S. Raymond

2Del original “archive files”.

3Linux Documentation Project.

4Del original “tidbit”

Acerca de Isildur Fuentes

Apasionado de las buenas historias y aikidoka de la tierra.

Publicado el febrero 27, 2012 en Divulgación, Escritos, Programación y etiquetado en , , , , . Guarda el enlace permanente. 2 comentarios.

  1. He de darte las gracias por esta serie de artículos. Aunque sólo les he dado un vistazo general y no he profundizado todavía en ellos, es algo en lo que estoy falto de conocimientos a un nivel alarmante y que noto a la hora de trabajar en mis desarrollos, aunque lo haga a nivel individual. De nuevo gracias a ti y a todos los que compartís conocimientos por la red.

A %d blogueros les gusta esto: