Las siguientes instrucciones son para el administrador de liberaciones, y detallan cómo liberar una nueva versión oficial.
Consulta la documentación del proceso de liberación para más detalles sobre tiempos.

Liberación beta (liberación previa)

  • Decide desde qué commit quieres que empiece la beta.
  • Esta será la rama de partida para la nueva versión. Antes (pero después de la versión «final» anterior), se puede mezclar master en beta en cualquier momento. A continuación, la rama master seguirá adelante y las solicitudes de cambio necesarias para esta versión deberían tener como destino beta.
    • Generalmente master debería estar sana (se superan todas las pruebas y no hay regresiones conocidas)
    • Antes el commit seleccionado debía garantizar que el cambio más reciente (y significativo) debía haber tenido al menos una semana de pruebas alpha. Esta restricción se ha relajado un poco para acelerar el proceso beta. Los desarrolladores principales deberían usar su criterio para elegir un punto de ramificación adecuado. Si es necesario, se pueden revertir los cambios o añadir cambios nuevos para corregir fallos en la beta.
  • Crea una rama a partir de este commit, crea una solicitud de cambios desde ella y pon beta como destino
    • Permite que otros puedan revisar el commit seleccionado, y lo que se incluirá en la liberación
    • Facilita la revisión de los cambios.
    • Haz una revisión del archivo user_docs/en/changes.t2t.
    • Solicita una segunda revisión, usa la solicitud de cambios y añade un enlace al diff del archivo de cambios, ya que el diff será bastante grande.
    • Una vez se hayan aprobado todas, mezcla en beta.
  • Crea una nueva etiqueta anotada.
    • Una beta no necesita una entrada de liberación previa en GitHub. Guárdatelas para las rc y las liberaciones
  • Espera a que AppVeyor complete la construcción.
  • Analiza el archivo del instalador
  • Publica la liberación efectuada.
  • Difunde la liberación.
  • Actualiza el identificador automático del hito
  • Actualiza la versión de NVDA en master

Durante el periodo beta

  • Mira periódicamente las incidencias recientes archivadas, específicamente las etiquetadas como p1, bug/crash o bug/app-crash.
  • Mira periódicamente las solicitudes de cambio basadas en beta y asegúrate de que son revisadas y luego aprobadas / mezcladas o rechazadas.
  • Según se vayan mezclando solicitudes de cambio basadas en la rama beta, crea nuevas etiquetas periódicamente.

Congelación de traducciones

  • Se considera el final del periodo beta después de la liberación de la última beta.
  • Congela las traducciones durante 2 semanas.
    • Llegados a este punto, no se deberían enviar más commits a la rama beta.

Segunda congelación de traducciones

Normalmente no hace falta. Sin embargo, a veces es necesario modificar las cadenas de traducción para resolver una incidencia crítica tras iniciar o completar la congelación de traducciones. Para hacerlo:
* Comprueba que beta tiene los cambios que requieren volver a traducir.
* Vuelve a hacer los pasos descritos en el documento Iniciar una congelación de traducciones.
* Envía un correo electrónico a la lista de correo de traducciones describiendo la necesidad de nuevos cambios y plazos.

Candidatas a liberación (liberaciones previas)

  • Comprueba que es seguro publicar una rc.
    • Mirando las incidencias archivadas recientemente, buscando específicamente las etiquetadas como p1, bug/crash o bug/app-crash.
  • Comprueba las solicitudes de cambio para beta.
  • Revisa si hay solicitudes de cambio hacia rc, ya que es probable que ocurran después de liberar la primera rc.
  • Si se trata de la rc1, actualiza las traducciones:
    1. Inicia sesión en exbi
    2. Cambia al usuario nvdal10n: sudo su nvdal10n
    3. cd ~/mr/mainNVDACode
    4. mr up
    5. cd ../srt
    6. mr up
    7. mr svn2nvda
      • Esto podría durar unos minutos
      • Busca errores del tipo Unable to push.
    8. Teclea exit para volver a tu propio usuario.
    9. Nota: esto actualiza beta con las nuevas traducciones.
  • Actualiza la rama rc localmente y envía los cambios a GitHub
    • Para la rc1, restablece la rama rc a beta
    • Para la rc1 y posteriores, mezcla beta en rc
  • Crea una etiqueta anotada.
  • Crea una nueva liberación previa en GitHub
  • Espera a que AppVeyor complete la construcción.
  • Analiza el archivo del instalador
  • Publica la liberación efectuada.
  • Difunde la liberación.

Liberación final

Crear la liberación / etiqueta anotada

  • Haz checkout de la versión a liberar.
    • git fetch
  • git checkout origin/<rama>
  • Donde <rama> es:
    • Para una beta: beta
    • Para una RC: rc
    • Para una liberación: rc
  • Crea una nueva etiqueta anotada en Git, y envíala a GitHub.
  • Crear etiqueta: git tag -a <nombre de etiqueta> -m "<mensaje>"
    • La etiqueta debe tener un prefijo release-. Por ejemplo:
      – Beta: Release-2019.2beta3
      – Rc: Release-2019.2rc1
      – Liberación: Release-2019.2
    • La primera línea del mensaje debería contener el título de la liberación. Por ejemplo:
      – Beta: Release 2019.2beta3
      – Rc: Release 2019.2rc1
      – Liberación: Release 2019.2
    • El mensaje puede contener información extra (dejando una línea en blanco) relevante para esta liberación en concreto.
  • Envía a GitHub: git push origin <nombre de etiqueta>
    • Al etiquetar la liberación se dispara automáticamente la compilación en appveyor, como parte de esto se efectuará la liberación.
    • Ahora la liberación se mostrará en la página de versiones de desarrollo (bajo beta o rc)
    • El sistema de actualizaciones automáticas comenzará a ofrecerla a aquellos que busquen betas

Conversión de una etiqueta anotada en una liberación de GitHub

  • Visita la página de nueva liberación de GitHub
  • Haz clic en el botón de menú tag, mostrado como «…», y elige «Create release»
  • Ejemplo de título de liberación: Release 2019.2beta3,
  • No hace falta descripción para la primera liberación o rc
    • Las siguientes rcs pueden describir adiciones o eliminaciones importantes.
  • Si es una versión rc, asegúrate de que la opción «This is a pre-release» está marcada.

Razonamiento

Las «releases» de GitHub tienen un formato diferente, pueden incluir metadatos como ‘pre-release’ y pueden tener binarios adjuntos. En el futuro, a NV Access le gustaría migrar a un sistema más automatizado que cree las liberaciones desde el script de Appveyor y adjunte los binarios. Por desgracia, las liberaciones de GitHub no crean una «etiqueta anotada» en Git, por lo que la etiqueta para la liberación no dispone de fecha o mensaje.

Analiza la compilación

  • Utiliza VirusTotal.
  • Simplemente envía la URL de descarga del artefacto de appveyor
  • Recientemente, usar la URL de Appveyor ha dado como resultado una incidencia («CRDF») en uno de los 72 analizadores.
  • Continúa analizando con la URL de NV Access, ya que el analizador «CRDF» no la identifica como problemática.

Publica la liberación efectuada

  • Conéctate a exbi
  • Cambia al usuario nvaccess: sudo su nvaccess
  • Ejecuta nvdaRelease
  • Esto confirmará el fichero actualmente almacenado.

Difunde la liberación

  • Crea una entrada de blog en www.nvaccess.org
    • Usa como base una publicación anterior.
  • Usa un enlace al archivo en NVAccess.org, los artefactos de compilación de Appveyor caducan tras seis meses.
    • Para rc y beta: pon la entrada en la categoría development.
    • Excluyendo la primera liberación de prueba, incluye los cambios desde la liberación de prueba anterior.
    • Para la versión final: pon la entrada en la categoría releases.
    • Nunca debería situarse en la categoría News.
  • Publica en la lista nvda-devel
  • Publica en la lista nvda-translations
  • Publícala en Twitter
  • Publica la noticia en Facebook.
  • Publica la noticia en la lista de correo de noticias de NV Access.

Actualización del identificador automático del hito

Esto se asegura de que el hito correcto se ha establecido en incidencias y solicitudes de cambio cerradas ahora automáticamente por GitHub.
1. Obtén el id del hito para la nueva liberación.
– Ve a https://github.com/nvaccess/nvda/milestones
– Mira la URL del enlace del hito relevante.
– El número al final es el id.
1. Inicia sesión en exbi
2. Cambia al usuario nvaccess: sudo su nvaccess
3. Edita ~nvaccess/data/nvaServer.conf
4. En la sección [nvdaGithub], cambia el valor de autoCloseMilestone al identificador id del hito que has obtenido en el paso 1.
5. Guarda el archivo y teclea exit para volver a tu propio usuario.
6. Recarga uwsgi para que los cambios tengan efecto: sudo systemctl reload uwsgi

Actualización de la versión de NVDA en master

En el código de NVDA, asegúrate de que el número de versión de la rama master y el archivo de cambios estén correctos
1. En source/buildVersion.py, actualiza las variables version_year y/o version_major para la próxima versión.
– Si la próxima versión es la primera del año en curso, (por ejemplo, 2018.1), actualiza copyrightYears también.
2. Añade un encabezado para la siguiente versión en user_docs/en/changes.t2t si todavía no existe.