Haciendo un ciclo de lanzamiento con un producto que se entrega a través de RPM

Question

Acabo de empezar a trabajar por primera vez con un producto que se entrega a través del mecanismo de Linux RPM, más que como una instalación independiente, y se dio cuenta de que esto hace que el ciclo de prueba / versión un poco más complejo.

Cuando estaba trabajando con los instaladores, que sólo iba a cambiar la estructura de numeración en nuestro sistema de construcción para marcar una acumulación como una prueba o liberar candidato en lugar de una instantánea de desarrollo, y decirle a la gente para instalar sólo el candidato a construir para la prueba. El problema de hacer eso con RPM es que si cambiamos el sistema de numeración, vamos a romper el mecanismo de entrega y máquinas instaladas no vamos a ser capaces de decir que es la última versión de RPM más.

La mejor manera que he pensado de evitar esto es para poner las RPM candidatos en un repositorio RPM completamente separados, pero esto también se complica porque tenemos múltiples RPM procedentes del mismo repositorio que se encuentran en diferentes ciclos de lanzamiento, por lo que vamos a estar tratando de tirar de la versión Release Candidate de RPM a partir del nuevo repositorio al mismo tiempo querer obtener instantáneas de desarrollo de RPM B desde el repositorio de desarrollo.

Esto debe ser un asunto muy común para el software de Linux, por lo que puede alguien decirme la mejor práctica? Gracias de antemano .....

Answer 1

Una metodología común en el mundo de Linux es tener una convención número de versión ampliamente publicitado que indica si la acumulación es el desarrollo o la liberación. Para el propio núcleo de Linux, versiones puntuales impares (2.5, 2.7) son el desarrollo, mientras que incluso (2.4, 2.6) son comunicados.

Un análisis rápido de la RPM guiar parece indicar que el uso de un esquema como esta puede ser la mejor opción.