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).

Cambios al proceso existente

El proceso descrito más adelante en este documento ha sido implementado hace muy poco. Por lo tanto, esta primera sección habla de los cambios específicos del proceso antiguo.

Objetivos y razones

El objetivo principal de estos cambios es suprimir la necesidad de una rama “next” e incubación de solicitudes de cambio. Las principales razones son:
* En la rama next era necesario mezclar manualmente las solicitudes de cambio. Esto no encajaba bien en la infraestructura de Github, y por tanto las mezclas incubadas no se rastreaban muy bien, las reversiones estaban desordenadas y en ocasiones era necesario recrear la rama next, las solicitudes de cambios generalmente hacían conflictos en next con otras solicitudes, lo que significaba que había que solucionar los conflictos tanto en next como en master.
* Hasta hace poco, la incubación era la única forma de garantizar algún tipo de calidad en el código. Ahora hay un número creciente de pruebas unitarias, las pruebas del sistema van por buen camino, y la gestión de solicitudes de cambio de Github (incluidas las revisiones obligatorias del código) aseguran una calidad mínima del código que antes no existía.

Cambios para desarrolladores

  • Una vez que los revisores aprueben una solicitud de cambios y se superen todas las comprobaciones de compilación, la solicitud se mezclará directamente en master. Ya no hay incubación en next.
  • Si una solicitud de cambios mezclada incluye una regresión, un fallo nuevo o no funciona como se indica, los desarrolladores principales serán un poco más estrictos que antes al revertirla.

Cambios para evaluadores

  • La rama next y las versiones instantáneas de desarrollo next dejarán de existir. Se actualizarán automáticamente a las nuevas versiones “alfa” todas las next. Las versiones alfa se crean a partir de 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.
  • Se actualizará a cualquiera que utilice versiones master a la primera versión beta etiquetada para la liberación actual que esté disponible.
  • La página de versiones de desarrollo en https://www.nvaccess.org/files/nvda/snapshots/ ahora lista tanto todas las versiones alfa como las versiones beta.

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.

Fase de desarrollo

  • El trabajo debería hacerse en ramas independientes según el tema del que traten.
  • Una rama de un tema concreto debería ser enviada para incluirla mediante una solicitud de cambios (pull request).
  • Todas las solicitudes de cambio deben seguir la plantilla proporcionada.
  • Las solicitudes de cambio deben basarse en la rama master de NVDA a menos que un desarrollador principal especifique lo contrario.
  • Las solicitudes de cambios enviadas no deberían contener cambios en 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.
  • 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.
  • Versiones de desarrollo compiladas de master (conocidas como instantáneas alfa) quedarán a disposición del público para pruebas tempranas. Su código es muy inestable y nunca deberían utilizarse en entornos de producción.
  • Hasta siete semanas antes de una liberación, se mezclará en una rama “beta” un commit reciente que se sepa que funciona bien de master (es decir, que supera las pruebas de compilación), dejando el código disponible para su traducción. La rama beta en ese momento debería seguir considerándose inestable, y no se recomienda para gente que no vaya a probar las traducciones.

La fase beta

  • Siete semanas antes de la liberación, dejarán de hacerse mezclas de master a beta. Se deberían plantear las nuevas solicitudes de cambios para mezclarse directamente en beta, sy y sólo si solucionan un fallo introducido en el ciclo actual de liberación o hay un cambio crítico en el sistema operativo fuera del control de los desarrolladores.
  • Si se realiza algún cambio a beta, como la fusión de pull requests o la integración de traducciones, se fusionará beta de vuelta a master periódicamente.
  • Empezando cinco semanas antes de la liberación final, se publicarán periódicamente versiones etiquetadas como beta, permitiendo que la mayor parte de la comunidad las pruebe. En este punto, el código introducido mediante master habrá sido probado durante al menos dos semanas, por lo que las compilaciones beta tienen calidad de beta.
  • 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 revertir la solicitud. Las razones a favor de no revertir la solicitud de cambios pueden ser:
    • El fallo es suficientemente trivial como para que un colaborador lo solucione.
  • 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

  • Tres semanas antes de que se libere la versión definitiva, la rama beta entrará en modo congelación de cadenas traducibles durante dos semanas. Esto significa que no se permitirán los cambios que afecten al texto de las traducciones. Los errores de ortografía y gramática que estén en la documentación pueden arreglarse, pero no hay que cambiar las cadenas traducibles con Gettext del código.
  • Sólo se deben enviar a la rama beta actualizaciones de traducciones y solucionar pequeños errores.

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 commits durante 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

  • Generalmente, las versiones finales saldrán alrededor del 22 de febrero, 22 de mayo, 22 de agosto y 22 de noviembre. La fecha exacta para cada versió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. 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 una rama separada y relacionada con el tema sobre el que se trabaja.
  • Se debe incluir cualquier documentación relevante en la rama temática en cuestión.
  • Las nuevas órdenes, controladores, ajustes, diálogos, etc. deben documentarse en la guía de usuario.
  • Las ramas temáticas deberían enviarse como solicitudes de cambio hacia master, a menos que un desarrollador principal haya solicitado 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.

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, pero generalmente estará cerca de las 00:00 UTC el 14 de febrero, 14 de mayo, 14 de agosto y 14 de noviembre. Cualquier trabajo que se envíe tras estas fechas no se incluirá en la próxima versión, quedará para la siguiente.

Para evaluadores

  • Las liberaciones beta están en estado beta. Incluyen código que irá en la próxima versión, y que se ha evaluado sin informar de problemas durante al menos una semana.
  • La rama master tiene código que se está probando para ver si se incluye en próximas versiones. Este código podría no haberse probado mucho, y podría contener fallos importantes.