Las actualizaciones siempre llegan antes que las notas de la versión

When I get that “New Discourse version, update available” email from my forum (this time about 2.1.0.beta1), I know @jomaxro 's elaborate release notes will appear here within 6-24 hrs. or so. It’s not very important, but I would organize it in a different order.

1 me gusta

I agree, first thing I do is go and look at the release notes to determine whether or not I am going to apply the update.

2 Me gusta

There is a high level release note list here: Discourse Version 2.1

1 me gusta

The notes are in the above topic, so this is covered.

I’m not seeing any notes specifically for 2.1b1. Just a general list of goals for the final version of 2.1.

I’m off today (family event), will respond to this properly next week. Short version: there are no major changes from the last release notes (2.0.0.beta10) and 2.1.0.beta1 - we simply pushed 2.0 to stable and moved work to 2.1.

4 Me gusta

Esta publicación se actualizó por última vez el 2021-06-28T04:00:00Z para detallar los procesos actuales.

¡Hola a todos! Hay varios temas que abordar aquí; veamos si puedo cubrirlos todos.

Esta fue una decisión intencional de nuestro equipo. No tenemos un sistema de lanzamiento formal para nuestras versiones beta. Lanzamos una nueva versión cuando nos parece oportuno hacerlo. Por lo tanto, generalmente hay poca advertencia antes de un lanzamiento y, en consecuencia, poco tiempo para redactar las notas de lanzamiento. @codinghorror decidió que no tenía sentido retrasar un lanzamiento esperando a que las notas estuvieran listas.

Las versiones beta ahora están coordinadas entre los equipos de ingeniería y de la comunidad. Las notas de lanzamiento deberían estar en línea al mismo tiempo que las versiones beta, si no un poco antes.

No verás notas de lanzamiento para la beta1. Para evitar confusiones, las notas de lanzamiento se redactan para todas las versiones beta. Las versiones estables también recibirán notas. Ten en cuenta que la beta1 (de cualquier versión) es prácticamente idéntica a la última beta de la versión anterior.

Para entender por qué es así, necesito explicar un poco cómo están configuradas nuestras ramas.

Para nuestros propósitos aquí, necesitamos conocer 4 ramas de Discourse: main, tests-passed, beta y stable.

Main:
Cuando se agrega un nuevo commit a Discourse, está en la rama principal. Main es la rama absolutamente más reciente (más actual) de Discourse y no recomendamos que nadie ejecute su sitio siguiendo la rama main.

Tests-passed:
Cuando se envía un nuevo commit a la rama main, nuestro servidor de compilación ejecuta automáticamente todas nuestras pruebas contra el código más reciente. Una vez que todas pasan, el commit se agrega a nuestra rama tests-passed. Esta es la rama que ejecutan todos los sitios de Discourse de forma predeterminada.

Beta:
Cada pocas semanas, movemos los commits actuales de tests-passed a beta. Usamos beta como un “hit” para lanzar una colección de commits que queremos que más sitios ejecuten y prueben. También lanzamos una beta si tenemos una corrección de seguridad importante que queremos que los sitios reciban. Cuando se lanza una beta, todos los sitios que ejecutan tests-passed o beta reciben el correo de “nueva actualización disponible”. Los sitios que ejecutan tests-passed se actualizarán a los commits actuales de tests-passed (incluidos cualquier nuevo commit enviado después de la beta), mientras que los que están en beta no lo harán.

Stable:
Cada 4-6 meses lanzamos una nueva versión stable. Aproximadamente 2 semanas antes de lanzar la versión estable, lanzamos nuestra última beta. Luego, vigilamos nuestros registros de cerca para intentar detectar cualquier error persistente que exista y evitamos agregar nuevas funciones o cambios arriesgados. Una vez que estamos satisfechos con el estado de la beta actual, la lanzamos a estable.


Entendiendo lo anterior, usemos la versión 2.0.0 como ejemplo. Lanzamos la 2.0.0.beta10 el 16 de mayo. Todos los usuarios que ejecutaban tests-passed o beta recibieron un correo (y asumimos que se actualizaron). Escribí las notas de lanzamiento para esa beta. Aproximadamente 2 semanas después, el 31 de mayo, lanzamos esa versión como estable bajo el nombre 2.1.0. Para asegurar que los usuarios que ejecutan tests-passed o beta también reciban la actualización, lanzamos la misma versión como 2.1.0.beta1.

¿Tiene sentido todo esto? ¿Hay algo que podría hacer de manera diferente en el canal release-notes de #feature:announcements para hacer esto más claro?

20 Me gusta