Ir al contenido principal
Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Procedimiento de Lanzamiento

Este documento es una guía para el equipo central, proporcionado públicamente para garantizar transparencia en el proceso de lanzamiento.

Control de Versiones​

Jellyfin utiliza el versionado semántico. Todos los lanzamientos tendrán versiones en formato X.Y.Z, comenzando desde 10.0.0. Sin embargo, tenga en cuenta que la cadena de versiones 10.Y.Z representa la "limpieza de la base de código", por lo que debe aceptarse que 10.Y.Z romperá toda compatibilidad, en algún momento, con interfaces compatibles con Emby anteriores, y también puede romper compatibilidad con versiones previas de 10.Y si es necesario para trabajos de limpieza posteriores. Nuestro control de versiones seguirá típicamente estos patrones:

X: Versiones Mayores​

  • Rompe compatibilidad con las API HTTP o de complementos

Y: Versiones Menores​

  • Introduce nuevas características

  • Realiza cambios menores compatibles con versiones anteriores en las API

Z: Versiones de Corrección (Hotfix)​

  • Correcciones críticas de errores o cambios menores

Filosofía General de Lanzamientos​

Los lanzamientos generalmente se realizarán los domingos "cuando estén listos". Para lanzamientos mayores/menores, el "cuando estén listos" es bastante flexible y corresponde cuando el lanzamiento esté realmente estable sin errores críticos. Tras un lanzamiento mayor, cada domingo el equipo de administración debe revisar los PRs fusionados recientemente y, si se requieren backports, realizar un lanzamiento de corrección que incluya esos PRs.

Procedimiento para Lanzamientos Mayores​

Preparación​

  1. Las pruebas continúan mediante compilaciones nocturnas de master, por lo que master debe estar generalmente estable antes de proceder. La versión de master ya debe reflejar la próxima versión mayor (ej. X.Y.0).

  2. Una vez que master esté en estado estable tras trabajo extenso, anuncie una "golden nightly" inminente mediante el canal de Matrix/Riot jellyfin-dev y el Foro.

  3. Recopile información de pruebas y repita según sea necesario.

  4. Cuando el lanzamiento se considere estable y funcional, anuncie congelación total de PRs mediante el canal de Matrix/Riot jellyfin-dev.

  5. Permita una "golden nightly" adicional y al menos 48 horas de pruebas. Reinicie este proceso si se encuentran errores críticos importantes.

  6. Cuando se completen todas las pruebas y el lanzamiento permanezca estable, proceda.

Lanzamiento del Cliente Web​

  1. Cree una rama de lanzamiento en el repositorio jellyfin-web mediante CLI desde master, nombrada release-X.Y.z, donde X e Y son el nuevo número de versión, y z es una z literal. Empuje la nueva rama a GitHub.

  2. Cree un lanzamiento en GitHub para la nueva versión, basado en la rama recién creada release-X.Y.z. La etiqueta debe nombrarse vX.Y.Z (ej. vX.Y.0) y el lanzamiento titularse "Lanzamiento X.Y.Z". El cuerpo del lanzamiento debe contener únicamente este enlace, reemplazando la versión según corresponda:

    [Please see the release announcement on the main repository.](https://github.com/jellyfin/jellyfin/releases/tag/vX.Y.Z)

  3. Publica el lanzamiento.

Lanzamiento del Servidor​

  1. Cree una rama de lanzamiento en el repositorio jellyfin mediante CLI desde master, nombrada release-X.Y.z, donde X e Y son el nuevo número de versión, y z es una z literal. Empuje la nueva rama a GitHub.

  2. Crea un lanzamiento en GitHub para la nueva versión, basado en la rama release-X.Y.z recién creada. La etiqueta debe llamarse vX.Y.Z (ej. vX.Y.0) y el lanzamiento debe titularse "Release X.Y.Z". El cuerpo del lanzamiento debe contener los siguientes componentes:

    a. Un breve resumen inicial bajo el encabezado # Jellyfin X.Y.Z.

    a. Una lista de características, incluyendo enlaces a Fider si están disponibles, bajo el encabezado ## New Features and Major Improvements.

    a. Notas de lanzamiento importantes, categorizadas por plataforma relevante (ej. [All] o [Windows]), bajo el encabezado ## Important Release Notes.

    a. Si aplica, comentarios sobre FFmpeg bajo el encabezado ## FFmpeg.

    a. Un registro de cambios completo, organizado por repositorio con subencabezados ### [repo](https://github.com/jellyfin/repo), bajo el encabezado ## Changelog. Cada elemento debe incluir el número de PR y su título.

  3. Publica el lanzamiento.

  4. Espera a que se completen las compilaciones.

  5. Anuncia el nuevo lanzamiento en el canal jellyfin-announce de Matrix/Riot y en el Foro.

Procedimiento para Lanzamientos de Correcciones Críticas (Hotfix)​

  1. Durante el trabajo habitual en la rama master, selecciona las PRs adecuadas para retroportar etiquetándolas con stable-backport durante su ciclo de vida. Todas las PRs apuntarán a master, por lo que las correcciones de errores para la versión estable deben llevar esta etiqueta para ser incluidas.

  2. Recopila la lista de PRs con stable-backport fusionadas desde todos los repositorios relevantes.

  3. Para cada repositorio, realiza una reconciliación de rama estable para las PRs relevantes:

    1. Para cada PR seleccionada para retroportar:

      1. Obtén el hash del commit de fusión para la PR desde la rama master.

      2. Aplica el commit de fusión en la rama release-x.y.z mediante: git cherry-pick -sx -m1 <merge-commit-hash>.

      3. Resuelve cualquier conflicto de fusión, generalmente manteniendo lo incluido en el merge. Si hay conflictos significativos, probablemente indica que la corrección es demasiado grande para retroportar.

      4. Finaliza el cherry-pick con: git add y git commit -v.

    2. Para el repositorio principal jellyfin, actualiza la versión a la nueva de hotfix usando el script bump_version y confirma los cambios con el mensaje "Bump version for X.Y.Z".

    3. Sube la rama de lanzamiento actualizada a GitHub.

Cliente Web​

  1. Crea un lanzamiento en GitHub para la nueva versión, basado en la rama release-X.Y.z relevante. La etiqueta debe llamarse vX.Y.Z y el lanzamiento titularse "Release X.Y.Z". El cuerpo del lanzamiento debe contener solo el siguiente enlace, actualizando la versión según sea necesario:

    [Please see the release announcement on the main repository.](https://github.com/jellyfin/jellyfin/releases/tag/vX.Y.Z)

  2. Publica el lanzamiento en GitHub y el repositorio de archivos.

Servidor​

  1. Crea una versión en GitHub para la nueva versión, basada en la rama correspondiente release-X.Y.z. La etiqueta debe llamarse vX.Y.Z y el lanzamiento debe nombrarse "Release X.Y.Z". El cuerpo del lanzamiento debe contener los siguientes componentes:

    a. Un breve resumen inicial bajo un encabezado # Jellyfin X.Y.Z.

    a. Una lista de notas de lanzamiento conocidas, categorizadas por plataforma relevante (ej. [All] o [Windows]), bajo un encabezado ## Important Release Notes.

    a. Si corresponde, notas/comentarios sobre FFmpeg bajo un encabezado ## FFmpeg.

    a. Un registro de cambios completo, dividido por repositorio con subencabezados ### [repo](https://github.com/jellyfin/repo), bajo un encabezado ## Changelog. Cada elemento debe incluir el número de PR y su título.

  2. Publica el lanzamiento.

  3. Espera a que finalicen las compilaciones.

  4. Anuncia el nuevo lanzamiento en el canal jellyfin-announce y en otros lugares requeridos.