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.

Iniciar un nuevo ciclo de desarrollo

  • Crea una solicitud de cambio para establecer el punto que da fin a la rama (merge commit, no squash merge)
    • Primero, crea una nueva rama (por ejemplo, branchFor2020.3) basada en el commit de master que debería usarse para la beta.
      – Usar una rama separada garantiza que master puede seguir avanzando sin afectar a la solicitud de cambios.
    • La solicitud de cambios permite que otros puedan revisar el commit seleccionado, y lo que se incluirá en la liberación
    • La solicitud de cambios facilita la revisión de los cambios.
    • Haz una revisión del archivo user_docs/en/changes.t2t, pero no añadas lo más destacado, mira el paso siguiente.
    • 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.
    • Decide desde qué commit quieres que empiece la beta:
      • Este será el punto de finalización de rama para la próxima liberación.
      • Antes de que se descontinúe la rama (pero después de la versión «final» anterior), se puede mezclar master en beta en cualquier momento.
      • Después de que el punto de master del que nace la rama avance las solicitudes de cambios necesarias deberían tener como destino la rama 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 solicitud de cambios añadiendo lo más destacado de esta versión (squash merge).
    • Basada en ramaParaX
    • Con destino ramaParaX o beta dependiendo de si ya se ha mezclado la solicitud de cambios de rama.
  • Crea una solicitud de cambios para mover master al siguiente ciclo de desarrollo de versión (squash merge).
  • Crea una solicitud de cambios para actualizar Espeak, y crea una nueva incidencia en el repositorio de Espeak-NG solicitando una nueva versión. Consulta la discusión.
  • Si se trata de una versión 20XY.1, crea una solicitud de cambios para actualizar la versión BACK_COMPAT_TO de la API de complementos para que coincida con el número de versión de este ciclo de liberaciones.
    • No es necesario mezclar esta solicitud de cambios hasta que se ramifique en la beta de la versión 20XY.1.
    • La intención de la existencia de esta solicitud de cambios es actuar como un aviso temprano de lo que está por venir para los desarrolladores de complementos.

Liberación beta (liberación previa)

  • Crea una nueva etiqueta anotada.
  • Espera a que AppVeyor complete la construcción.
    • Plantéate redactar un borrador de la publicación de la versión.
  • Analiza el archivo del instalador
  • Una beta no necesita una entrada de liberación previa en GitHub. Guárdatelas para las rc y las liberaciones
  • Publica la liberación efectuada.
  • Difunde la liberación.

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.
  • Espera a que AppVeyor complete la construcción.
    • Plantéate redactar un borrador de la publicación de la versión.
  • Analiza el archivo del instalador
  • Crea una nueva liberación previa en GitHub
  • 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

  • Una beta no necesita una entrada de liberación previa en GitHub. Guárdatelas para las rc y las liberaciones
    • No hemos sido consistentes con esto en el pasado.
  • 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.2rc1,
  • Añade una descripción que apunte a la publicación de la liberación en nvaccess.org:
  • Highlights and download links can be found in the release blog post at: https://www.nvaccess.org/post/nvda-2021-1rc2/
    • Las siguientes rcs / Liberaciones 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.
  • Envía la URL de descarga del sitio de NV Access.
  • 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.

Nueva sección en el archivo de cambios

Añade al principio del archivo de cambios:

= 20XY.Z =

== New Features ==


== Changes ==


== Bug Fixes ==


== Changes for Developers ==
  • Si se trata de una versión 20XY.1 añade esto a la sección «Changes for developers»:
    - Note: this is a Add-on API compatibility breaking release. Add-ons will need to be re-tested and have their manifest updated.