Para obtener más información sobre todos los cambios publicados en la versión 2026.7, consulta:
También se han publicado versiones de parche para otras versiones compatibles:
4 Me gusta
¿Se convierte esto en la versión «esr» actual o me he equivocado en algo?
1 me gusta
En efecto, no logro entender qué ha ocurrido. Para esta actualización (muy urgente debido a Cache poisoning/XSS via color scheme cookies · Advisory · discourse/discourse · GitHub) se requería una reconstrucción, pero como había un cambio de versión v2026.1.5 → v2026.1.6 en el registro de cambios, asumí que sería un aumento menor de versión. Pero no, ahora estoy en v2026.7.0. Por lo que sé, mi foro está configurado para estar en esr :
params:
db_default_text_search_config: "pg_catalog.english"
## Establece db_shared_buffers hasta un máximo del 25% de la memoria total.
## se establecerá automáticamente durante la inicialización basado en la RAM detectada, o puedes anularlo
db_shared_buffers: "2048MB"
## puede mejorar el rendimiento de ordenación, pero añade uso de memoria por conexión
db_work_mem: "40MB"
## Reduce el tamaño máximo de carga
upload_size: 1m
## ¿Qué revisión de Git debería usar este contenedor? (predeterminado: tests-passed)
version: esr
También me sorprendió bastante ver un montón de consultas posteriores a la actualización como esta:
== 20260421061908 AddCoveringIndexOnChatMessagesThreadId: migrando ===========
-- remove_index(:chat_messages, {name: "idx_chat_messages_thread_id_id_user_id_not_deleted", algorithm: :concurrently, if_exists: true})2026-07-28 16:02:43.673 UTC [544] discourse@discourse LOG: duración: 16903.716 ms statement: CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_localization" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:02:59.214 UTC [544] discourse@discourse LOG: duración: 15529.318 ms statement: CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_locale_detection" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.031 UTC [544] discourse@discourse LOG: duración: 798.943 ms statement: CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_locale_detection" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.186 UTC [544] discourse@discourse LOG: duración: 143.500 ms statement: CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_localization" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:03:01.251 UTC [544] discourse@discourse LOG: duración: 1051.872 ms statement: UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 1
AND id < 10001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2026-07-28 16:03:01.910 UTC [544] discourse@discourse LOG: duración: 658.965 ms statement: UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 10001
AND id < 20001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2 Me gusta
¡Sí, es así!
Esta versión es una nueva versión ESR, por lo que pasaste a ella cuando actualizaste.
3 Me gusta
¿Se podría hacer esto menos confuso en el futuro? Quizás sea solo yo, pero si se aplica una actualización a la rama ESR en la que me encuentro, asumo que es porque la versión principal actual de esa rama sigue recibiendo soporte.
2 Me gusta
2026.1 sigue siendo compatible, y puedes fijar tu instalación a esta versión estableciendo version: release/2026.1 en tu app.yml. En ese caso, ejecutar una reconstrucción habría incorporado la actualización de seguridad en la rama 2026.1.
Supongo que estabas usando version: esr. En ese caso, estás siguiendo la versión ‘última esr’, que ahora es 2026.7.
Puedes encontrar información sobre los períodos de soporte y las superposiciones entre los soportes ESR en https://releases.discourse.org/
Desafortunadamente, no es posible degradar Discourse. Pero si quieres evitar esto en el futuro, puedes fijar a release/2026.7 (y asegúrate de actualizar ese pin manualmente antes de que 2026.7 deje de ser compatible).
1 me gusta
Gracias. Supongo que busco la forma más infalible y automatizada de mantenerme definitivamente en la versión más antigua que aún tenga soporte, es decir, la ruta de desarrollo más lenta.
3 Me gusta
Aquí también, y creo que esr (casi) lo hace. Cada pocos meses hay un nuevo esr y te mudas a ese, lo cual es lo que acaba de ocurrir. Pero de hecho el antiguo esr tiene otros dos meses de vida útil mantenida, así que esperabas quedarte en ese esr anterior. (Creo que es algo razonable querer hacer eso. ¿Necesitamos una etiqueta esr-mantenido??)
4 Me gusta
Creo que es algo razonable considerar, pero también piensa en esto… ¿qué sería diferente dentro de 2 meses, una vez que v2026.1 deje de recibir mantenimiento?
Sin cambios adicionales, seguirías recibiendo actualizaciones en ese momento “sin previo aviso”.
¿Te parece bien?
1 me gusta
Sí, creo que sigue teniendo sentido querer mantenerse en la antigua versión ESR durante más tiempo. Esto implica que la nueva versión ESR ha pasado por alguna fase de pruebas y puede haber incorporado algunas correcciones.
Yo actualicé a la nueva versión ESR en menos de una hora y, en cierto modo, me arrepiento: en el mundo actual, lo más recomendable sería fijar la versión anterior y aplicar únicamente las correcciones de seguridad. Esto separa la corrección de seguridad urgente de la curva de aprendizaje administrativa y de cualquier nuevo error que pronto será corregido. Consulta la muy útil guía
Salto de la ESR 2026.1 a la 2026.7: lo que encontré
(¿Por qué esperar nuevos errores en una versión ESR recién lanzada? Porque, por lo que puedo ver, la nueva versión ESR estuvo en desarrollo continuo hasta el momento de su lanzamiento. No existe una fase de estabilización.)
2 Me gusta
Esa es la gran pregunta.
Así que, si estuviera en esr-maintained, entonces, después de dos meses, esr y esr-maintained serían la misma rama, ¿verdad? Así que, después de 2 meses, aún me sorprendería el gran cambio.
Mientras esr y esr-maintained no sean la misma rama, Discourse podría emitir/mostrar una advertencia de que has entrado en el «periodo de gracia ESR». Esta advertencia solo podría mostrarse en el foro a los administradores, y no al reconstruir el contenedor.
Tener un aviso anticipado sobre el cambio de versión ESR sería genial para que puedas planificar y probar la actualización durante este periodo de gracia con soporte.
4 Me gusta
En un mundo ideal, esto te da dos meses para actualizar tu servidor de staging al nuevo ESR, mientras que en Producción puedes seguir ejecutando el antiguo ESR con actualizaciones de seguridad para cubrir este período.
En efecto, tiene sentido tener algún tipo de seguimiento simple de etiquetas para seguir el antiguo ESR parcheado, de modo que recibas automáticamente las actualizaciones mantenidas del antiguo ESR.
¿Quizás ya hay una forma de lograr esto?
2 Me gusta
No creo que la versión ESR reciba tantas correcciones de errores. Al igual que la 2026.1, a partir de ahora solo recibirá actualizaciones de seguridad.
Así que, aunque dentro de un mes algunos de esos errores puedan ser conocidos, eso no significa que no tengas que lidiar con ellos.
3 Me gusta
Para adoptar una postura pesimista, ¡veremos! Imagino que si se encontrara algún cambio rompedor absurdo en una versión ESR recién creada, se corregiría. Quizás este nuevo mundo no ha estado en vigor el tiempo suficiente para ver que eso ocurra. De hecho, no esperaría correcciones para meras molestias.
1 me gusta