Este documento ofrece pautas generales para el desarrollo de versiones de NVDA. Todos los desarrolladores y traductores, tanto actuales como aquellos que potencialmente puedan serlo, deberían leer y seguir este documento. Estas pautas pueden romperse en circunstancias especiales. Cualquier detalle relacionado con este documento debe discutirse con los desarrolladores principales: Mick Curran (@MichaelDCurran) y Reef Turner (@feerrenrut).

Flujo de trabajo de versiones

Este es el flujo de trabajo general de publicación de versiones. En las siguientes secciones se ofrece información para grupos específicos de la comunidad. La producción de una liberación consta de lo siguiente:
1. Fase de desarrollo
– El desarrollo se hace en paralelo con el proceso de liberación de la versión anterior. Por ejemplo, NVDA 2020.2 se encuentra en desarrollo mientras NVDA 2020.1 se encuentra en fase de liberación
2. Fase de liberación
– Pruebas finales y trabajos de traducción previos a la liberación.

Fase de desarrollo

  • Las contribuciones se hacen siguiendo las especificaciones de la sección «Para desarrolladores» de este documento
  • Una vez que una solicitud de cambio ha sido revisada y aprobada por al menos un colaborador de NVDA y todas las comprobaciones de compilación se han superado, un desarrollador principal hará un commit final a la solicitud de cambio que actualice changes.t2t, y después mezclará la solicitud de cambio en master.
  • Si la mezcla de una solicitud de cambios en master causa que falle cualquier comprobación de compilación en master, la solicitud se revierte sin preguntar. Sin embargo, esto probablemente no será un problema, ya que las comprobaciones de compilación en la solicitud en sí deberían haberse superado.
  • Si una solicitud de cambios mezclada se ha identificado como causante de un fallo nuevo, una regresión, o no funciona como se informó originalmente, los desarrolladores principales pueden revertir la solicitud. Las razones a favor de no revertir la solicitud de cambios pueden ser:
  • La solicitud de cambios fue enviada por un colaborador activo y se sabe con certeza que volverá con otra solicitud de cambios para solucionar los problemas.
  • El fallo es suficientemente trivial como para que un colaborador lo solucione.
  • Las ‘versiones de desarrollo Alpha’ se ponen a disposición del público para realizar pruebas en una fase muy temprana. Consulta la sección «Para evaluadores» de este documento

Fase de liberación

La fase de liberación está destinada a refinar la liberación, con pruebas de audiencias extensas, ytraducciones incorporadas.
Cuando no se encuentren incidencias que bloqueen el proceso, se espera que se desarrolle en 5 semanas:
– Compilaciones beta: 2 semanas para recibir cualquier corrección necesaria
– Las siguientes betas podrían durar una o dos semanas más, según la decisión de los desarrolladores principales
– 2 semanas para congelación de traducciones (que empieza 3 semanas antes de la liberación)
– RC: una semana.
– Si se encuentran problemas, los desarrolladores pueden decidir liberar otras RC durante una semana cada una.

Compilaciones beta

  • Se selecciona un commit sin problemas serios conocidos de la rama ‘master’ y se mezcla en ‘beta’, dibujando la línea límite con las características que incluirá esa versión.
  • Este commit habrá estado en master y, por tanto, en ‘versiones Alpha’ al menos 2 semanas y ya se puede considerar que tiene calidad beta.
  • Se creará una ‘versión beta’ etiquetada para pruebas más extensas.
  • Se puede plantear mezclar las nuevas solicitudes de cambio directamente en beta.
  • Si corrigen regresiones introducidas en esta versión.
  • Si corrigen un fallo en una característica que esta versión «debe tener».
  • Si corrigen un cambio crítico en el sistema operativo fuera del control de NV Access.
  • Se publicarán nuevas versiones etiquetadas como beta si se considera apropiado.
  • Se mezclará beta en master si es necesario.
  • Si hay solicitudes de cambios críticas o se mezclan traducciones.
  • Si una solicitud de cambios que llega a beta se identifica como causante de una regresión, un nuevo fallo o no funciona como se había indicado originalmente:
  • Los desarrolladores principales pueden decidir revertir la solicitud de cambios.
  • Un colaborador podría corregirla si el fallo es suficientemente trivial.
  • Si se revierte una solicitud de cambios en beta, es más que probable que las solicitudes de cambio que la sustituyan no entren en la versión actual.

Congelación de cadenas traducibles

  • La rama beta entrará en una congelación de cadenas traducibles.
  • No se permiten cambios en las cadenas que afecten a las traducciones. Se pueden hacer pequeñas correcciones gramaticales y ortográficas en los archivos de documentación, pero no se deben alterar las cadenas gettext del código.
  • Sólo se deben enviar a la rama beta actualizaciones de traducciones y solucionar pequeños errores en esta fase. De lo contrario, se debe extender el periodo de traducción durante una cantidad adecuada de tiempo.

Candidata a liberación (release candidate)

  • Después de la congelación de cadenas traducibles, se actualizará la rama «rc» basándose en la rama beta.
  • Se liberará la primera versión candidata inmediatamente desde la rama rc.
  • Después de esto, sólo se pueden enviar commits a la rama rc para solucionar problemas muy graves.
  • Pueden publicarse más versiones candidatas.
  • La versión final sólo puede crearse si no ha habido cambios significativos durante al menos una semana desde la última versión candidata.

Representación en GitHub

  • Para la mayoría de elementos, se abrirá una incidencia y se discutirán los cambios antes de enviar una solicitud de cambios.
  • Si se debería dar prioridad a una incidencia para que se incluya en una versión específica, su hito (milestone) debe establecerse a la versión deseada (por ejemplo, 2014.4).
  • Una vez se mezcle una solicitud de cambios en la rama master, el hito para la incidencia (si lo hay) y el de la solicitud de cambios deberían establecerse en el hito de la siguiente versión (por ejemplo, 2013.2) y el problema debería cerrarse y marcarse como resuelto.
  • Las incidencias y solicitudes de cambio para arreglar fallos en una versión candidata deberían tener el hito de dicha versión (por ejemplo, 2013.2).

Programación de liberaciones

  • En el pasado, se han liberado versiones de NVDA 4 veces al año. No se espera que esto cambie drásticamente. La fecha exacta para cada liberación será determinada por los desarrolladores principales.

Versiones de mantenimiento

  • Bajo extrañas circunstancias, se puede crear una versión de mantenimiento (por ejemplo, 2013.1.1).
  • Una versión de mantenimiento sólo puede incluir solución a fallos muy graves o problemas de seguridad.
  • Las versiones de mantenimiento se crean desde la rama rc.

Para desarrolladores

  • En la mayoría de los casos, se debe crear una incidencia en GitHub para cada problema existente y discutirla antes de enviar una solicitud de cambios. Esto se hace para dar tanto a los desarrolladores como a la comunidad una oportunidad para hacer comentarios sobre el enfoque y evitar decepciones y esfuerzo desperdiciado de los colaboradores. Sin embargo, aquellos cambios que sean triviales no necesitan una incidencia. Mira el artículo sobre cómo contribuir con NVDA para más información.
  • El trabajo debería hacerse en ramas temáticas. Incluyendo colaboradores externos.
  • Una solicitud de cambios que intente mezclarse desde la rama master de la bifurcación de un colaborador podría no obtener compilaciones automáticas a partir de ella.
  • Se debe incluir cualquier documentación relevante en la rama temática en cuestión.
  • La rama temática debería ser enviada para incluirla mediante una solicitud de cambios (pull request).
  • Las nuevas órdenes, controladores, ajustes, diálogos, etc. deben documentarse en la guía de usuario adecuadamente.
  • Todas las solicitudes de cambio deben seguir la plantilla proporcionada a tal efecto.
  • Las solicitudes de cambio deben basarse en la rama master de NVDA.
  • Un desarrollador principal puede pedir específicamente que la solicitud de cambios se haga hacia beta o rc en caso de que se solucionen fallos introducidos en el ciclo de la versión actual.
  • Las solicitudes de cambio enviadas no deberían contener cambios en el fichero changes.t2t.
  • En su lugar, las entradas del registro de cambios deberían situarse en la descripción de la solicitud de cambios, bajo la sección apropiada de la plantilla.
  • Todas las solicitudes de cambio enviadas deben tener la casilla de verificación «Allow edits from maintainers» marcada. Generalmente, este es el caso para todas las nuevas solicitudes de cambio en GitHub.

Para traductores

  • Todas las traducciones deben basarse en la rama beta.
  • Los traductores deben asegurarse de que su traducción esté lista un día antes de que finalice la congelación de cadenas de traducción para que sus cambios sean incluidos en la versión final. Los desarrolladores principales anunciarán la fecha límite cuando la congelación comience, en caso de dudas se puede consultar el tablón de mensajes de nvda-translations para buscar el anuncio de «congelación de traducciones». Cualquier trabajo que se envíe fuera de plazo no se incluirá en la versión que esté por hacerse.

Para evaluadores

  • Se pueden descargar liberaciones previas para pruebas (conocidas como «versiones de desarrollo») desde la página de versiones de desarrollo.
  • En ella se listan las ‘versiones alpha’, ‘versiones beta’ y las ‘candidatas a liberación’.
  • Las compilaciones alpha son inestables. Incluyen código que se está probando para su posible incorporación en versiones futuras, pero que no se ha evaluado mucho (o nada) todavía y podría tener problemas importantes. Las versiones alfa se crean a partir de la rama master cada vez que ésta cambia (p.ej. cuando se mezcla una solicitud de cambio). Como su nombre sugiere, estas versiones son de calidad alfa. Y aunque pasen las pruebas automáticas, estas versiones no han tenido evaluadores humanos.
  • Las liberaciones ‘beta’ están en estado ‘beta’. Incluyen código que irá en la próxima versión cuya estabilidad ha sido probada en las compilaciones alpha. Una característica se considera estable si ha permanecido en ‘compilaciones alpha’ al menos durante una semana.
  • En la mayoría de casos, las ‘liberaciones RC’ serán idénticas a la versión final.