Discourse no envía una versión LTS

General
1

No estaba al tanto de la compatibilidad con discourse, así que tendré que leer sobre eso.

Me gustaría abordar esto, porque parece que hay una gran desconexión entre cómo el equipo de Discourse concibe la rama estable y cómo el resto de la comunidad de Discourse/la comunidad más amplia de administradores de foros concibe la oferta estable de Discourse.

Razones clave por las que la rama estable no cumple con la definición de LTS.

1) El personal disuade activamente de usar la rama estable cada vez que se menciona.

No quiero necesariamente señalar a los publicadores individuales, pero aquí hay una selección de publicaciones del personal para mostrar el tema:

Tenga en cuenta que en algunos aspectos tests-passed es más estable que stable, ya que es lo que ejecuta discourse.org, por lo que es el que mejor se prueba.

Por lo tanto, Discourse se encuentra en un estado de beta perpetua, lo que significa que siempre estamos trabajando en nuevas funciones y refinamientos. En nuestro caso, beta no significa inestable; alojamos sitios con millones de visitas mensuales en nuestras versiones tests-passed y beta.

El canal estable no es necesariamente más “estable” que tests-passed. Se trata más de la idea de que los errores son conocidos y sirve como un punto de control para un conjunto específico de funciones y mejoras. Con tests-passed, pueden introducirse nuevos errores y luego corregirse unas confirmaciones después.

La comunicación ha sido bastante consistente en que Discourse está en “beta perpetua”, que no es la experiencia que los usuarios de producción/no desarrolladores quieren tener.

En una búsqueda rápida en DuckDuckGo de los diez primeros enlaces para “discourse stable”, ninguno parece abogar a favor de usar la rama estable. Por lo tanto, independientemente de su calidad real, si el personal guía universalmente a las personas para que no usen la rama estable, genera una impresión negativa en la mente de las personas de que no es apta para su propósito.

La rama estable puede ser excelente, pero si nos dicen una y otra vez que es mejor no usarla, no la consideraremos para implementaciones serias.

2. Una LTS recibe correcciones de errores más allá de las correcciones de errores de seguridad.

Una LTS es algo que no recibe actualizaciones de funciones, pero sí recibe correcciones de errores. Según los propios comentarios del personal, en Discourse no parece haber esfuerzos para retroportar correcciones de errores para problemas que no sean de seguridad. Quizás esto no sea cierto, pero esto es lo que se nos ha dicho.

3. Una LTS tiene pasos de instalación sencillos.

La guía de instalación ni siquiera menciona la existencia de la rama estable.

4. Una LTS es ampliamente utilizada.

Antes de tu publicación, no había oído hablar de un uso generalizado de la rama estable. ¿También se usa ampliamente en la práctica? Dado lo oculta que está, lo dudo, pero no tengo métricas para decirlo. Este es un factor importante porque da confianza a las personas para usar la rama estable en sus implementaciones de producción.

5. Una LTS tiene un ciclo de lanzamiento y notas de actualización claras.

No veo ninguna ubicación central donde la rama estable esté claramente documentada. (¡Puede que simplemente me la esté perdiendo!)

Mis expectativas para una LTS son una página que describa:

  • Versión de lanzamiento activa actual
  • Notas de lanzamiento que incluyen:
    • Cambios/funciones importantes entre versiones LTS
    • Pasos de migración desde la versión LTS anterior (especialmente cambios importantes a tener en cuenta)
  • Duración de soporte activo planificada para cada versión

por ejemplo: mediawiki, pero en realidad cualquier LTS importante de código abierto tiene páginas similares.

Esta documentación me ayuda a poder planificar cuándo habrá un cambio importante que requerirá tiempo de inactividad y/o intervención manual.

6. Una LTS no tiene cambios importantes que rompan la compatibilidad dentro de un ciclo de lanzamiento.

Este puede ser el caso de la rama estable, pero estoy demasiado acostumbrado a presionar el botón de actualización y que el foro se caiga como para saberlo con seguridad. Supongo que lo que busco aquí son advertencias más claras al pasar de versiones que rompen algo.

7. Una LTS proporciona advertencias de deprecación de API para al menos un ciclo de lanzamiento LTS completo.

Estos deberían medirse a un ritmo de un año o más, en lugar de un mes o más.

8. Una LTS está programada / tiene períodos de soporte superpuestos.

Cualquier LTS grande tendrá un período de soporte superpuesto entre dos versiones LTS. La rama estable parece simplemente hacer un cambio binario a la siguiente versión. (Mi impresión también puede estar errada debido a la falta de una página de documentación centralizada).

9. Es sencillo actualizar de una versión no LTS a una LTS.

No hay necesidad de soportar el retroceso, pero cuando hay una LTS disponible, no está claro cómo cambiar limpiamente de rama a LTS. Parece que hay algunas publicaciones en el foro al respecto, pero nuevamente, no encontré ninguna documentación centralizada.

Soy un fan de Discourse, pero este es un punto de dolor común que encuentro yo y muchas otras personas. Lo que es la rama estable ahora mismo es solo una rama, no una LTS.

4 Me gusta
2

Movido esto a su propio tema, parece no relacionado con la agrupación de plugins.

3 Me gusta
3

Si consideramos la cara triste en el panel de administración frente a estar tantos commits atrasados en “actualizar discourse”

¿es la actualización crítica parte de tests-passed y si “Actualizar todo” inmediatamente después de que la cara feliz se convierta en cara triste, estará sincronizado con tests-passed

4

Creo que esta actualización específica requiere reconstruir desde la consola. Dos veces.

1 me gusta
5

Discourse parece tener una velocidad bastante alta en términos de cambios y una hoja de ruta ambiciosa.

Para respaldarlo, necesita muchos comentarios de los usuarios. Creo que hay una estrategia implícita clara para promover tests-passed porque eso respalda la retroalimentación temprana sobre los nuevos cambios.

A cambio, el usuario obtiene software gratuito y nuevas funciones. Es una especie de pacto. Creo que con el tiempo este acuerdo ha demostrado ser exitoso.

La versión estable realmente no ayuda tanto al desarrollo, por lo que puede que no sea de interés comercial promoverla tanto (solo mi opinión, no hablo en absoluto en nombre de CDCK).

El otro problema con la versión estable es este, y es aún más significativo:

Normalmente hay muchos cambios entre las versiones estables, incluidas deprecaciones importantes y cambios en la API. La participación en tests-passed como desarrollador, administrador del sitio o creador de temas te da la oportunidad de abordar los cambios en pequeñas porciones manejables, en lugar de tener una gran montaña que escalar cada vez que alcanzas el próximo hito estable.

Para respaldar esos grandes saltos, probablemente necesitarás un sitio de staging y un montón de casos de prueba para revisar.

Si no posees ninguna personalización, podrías optar por la versión estable, pero dependes en gran medida de otros sobre los que podrías no tener una gran influencia para asegurarte de que los complementos que estás utilizando se mantengan adecuadamente para tu próxima actualización. Es posible que descubras que algunos elementos pierden soporte cuando llega el momento de actualizar y, en ese momento, podrías encontrarte en un aprieto. También puedes encontrar que el desarrollador no admite la versión estable en absoluto y podrías tener que bifurcar y preparar un “corte” del plugin para admitir tu versión estable. (sin embargo, hay un buen sistema de fijación implementado, por lo que no es una gran cantidad de trabajo)

La otra pieza significativa en Discourse es que está muy centrado en las pruebas unitarias, por lo que la rama test-passed suele ser muy buena desde una perspectiva de estabilidad.

4 Me gusta
6

Dado el rechazo de la gerencia a deshacer cambios impopulares como la agrupación de complementos, no creo que esta parte sea precisa. Quizás desde una perspectiva de QA, pero incluso entonces he tenido varios errores bastante complicados que no se han solucionado en el pasado. Al final del día, me doy cuenta de que son ellos quienes invierten tiempo y dinero en ello, por lo que pueden tomar sus decisiones, pero en mi opinión, no creo que sea una estrategia para obtener más retroalimentación.

Creo que la razón más realista por la que no admiten un LTS adecuado es que le costaría a alguien del equipo tiempo gestionarlo/documentarlo. Es una característica que beneficia principalmente a los autoalojados, por lo que imagino que se consideraría una pérdida de tiempo para ellos. Pero es una característica esperada y no tenerla es una desventaja real cuando los administradores de foros eligen su software de foro, ya que otros contemporáneos tienen ofertas más estables.

7

Por el contrario, creo que la agrupación de complementos es precisamente para promover su uso y, como resultado, obtener más comentarios.

8

La dirección mencionó específicamente problemas con la falta de coincidencia de versiones que afectan la productividad del equipo de desarrollo en el otro hilo. Lo cual es una justificación válida, pero no la forma ideal de resolver el problema de raíz, como se discutió en el otro hilo.