Per maggiori informazioni su tutte le modifiche rilasciate in 2026.1, consulta:
Questa è la prima versione “ESR” di Discourse e sostituisce il vecchio ramo “stable”. I siti che seguono stable verranno aggiornati da 3.5 a 2026.1 al loro prossimo aggiornamento. Per vedere tutte le modifiche da 3.5 a 2026.1, usa questo link.
Sono state rilasciate anche le versioni patch per le altre versioni supportate:
2026.1.0 sarà anche la prima versione esr.
Per le persone sul ramo stabile precedentemente esistente (che ora è aliasato a esr), si passerà da 3.5.3 a 2026.1.0; e non a 3.5.4
Quindi fammi capire, ho tempo fino ad aprile per non aggiornare (3 mesi) quando la v2026.1 verrà deprecata, la mia versione attuale sarà ESR, giusto? Tutti questi cambiamenti sono un po’ confusi.
Sì, a meno che non stiano usando il tag v3.5.4 per rimanere su 3.5.
Il diagramma sulla homepage di https://releases.discourse.org/ è il modo migliore per visualizzare le cose.
Indipendentemente dal flusso di rilascio che scegli, dovrai sempre aggiornare regolarmente per le correzioni di sicurezza critiche. La domanda è se vuoi anche ricevere nuove funzionalità e altre modifiche insieme alle correzioni di sicurezza (in tal caso, usa release o latest), o se preferisci avere una cadenza di circa 6 mesi per quelle (in tal caso, usa esr).
Siamo ancora agli inizi di questo nuovo schema di numerazione, quindi la documentazione e gli strumenti continueranno ad evolversi man mano che ci adatteremo al nuovo sistema.
Era la v2026.0 quando ho aggiornato l’ultima volta a dicembre e ora la v2026.2 diventerà ESR ad aprile, giusto?
Consulta la página de inicio de releases.discourse.org per tutte le informazioni di supporto. 2026.1 è la versione di supporto esteso corrente e sarà supportata fino a ottobre 2026.
2026.2 sarà rilasciata a febbraio e riceverà correzioni di sicurezza per 2 mesi dopo tale data. Non sarà una versione di supporto esteso.
La versione 2026.1.0 è la prima release stabile/ESR a interrompere il supporto per iOS e altri browser obsoleti? È un cambiamento abbastanza grande da dover essere elencato da qualche parte nelle note di rilascio. Non sono riuscito a trovare nulla a riguardo nella casella di ricerca delle “modifiche dettagliate” in fondo, però.
Oh, penso sia perché hai collegato al changelog per v2026.1.0-latest → v2026.1.0. Se lo cambi in v3.5.3 → v2026.1.0 allora mostra 2397 modifiche dettagliate, anziché solo 369. Per queste release ESR dovresti davvero collegarti all’ultima release ESR invece che a -latest (è come una RC?).
Ancora non riesco a vedere quale modifica abbia contrassegnato chiaramente l’interruzione del supporto per i vecchi browser, ma almeno ho trovato questa: FIX: Update 'modern mobile' regex following iOS 15 support drop by davidtaylorhq · Pull Request #34792 · discourse/discourse · GitHub
Sì 
Già. La stragrande maggioranza delle persone utilizza i rami latest o release di Discourse, quindi è per questo che il sito del changelog è ottimizzato. Le persone che scelgono ESR stanno essenzialmente “saltando 5 versioni” ogni volta che aggiornano, quindi dovresti guardare le modifiche per ciascuna di quelle versioni intermedie.
Puoi farlo sfogliando ogni changelog intermedio, oppure puoi usare i filtri per generare un changelog personalizzato che copra l’intero intervallo (come hai fatto tu). Forse possiamo migliorare l’esperienza utente del sito delle release per avere una sorta di collegamento rapido per passare da una versione ESR a un’altra.
Tornando all’ultima release “stabile”, non avevamo un “mega-changelog” nemmeno per quella. Le persone hanno dovuto leggere ciascuno dei changelog beta intermedi per avere un quadro completo delle modifiche. Quindi penso che ci stiamo muovendo nella giusta direzione qui: almeno ora è possibile vedere un changelog completo, anche se l’esperienza utente non è delle più fluide.
Per ora, ho aggiunto un link a quel confronto ESR → ESR nell’OP qui:
Grazie per il feedback!
Sia da una versione specifica a un’altra, sia da un punto arbitrario in latest all’ultimo latest, se una modifica tra i commit x e y non può essere applicata dall’aggiornatore integrato, richiedendo invece che il container venga ricostruito da una nuova immagine, il nuovo sistema di note di rilascio lo identificherà e prenderà nota della necessità di una ricostruzione?
Separamente, l’aggiornatore integrato impedirà l’aggiornamento, richiedendo una ricostruzione?
La mia vaga comprensione dell’aggiornatore integrato è che dopo aver aggiornato Docker_manager, bloccherà l’aggiornamento di Discourse se è necessaria una ricostruzione. Tuttavia, non l’ho visto formalizzato e aneddoticamente non è sembrato completamente affidabile.
Nello specifico, a volte navigando dall’aggiornamento completato di Docker_manager alla pagina Versioni, l’aggiornamento di Discourse sarà disponibile per l’avvio, e solo dopo aver aggiornato la pagina verrà bloccato. [Nota che l’ultima volta che l’ho visto accadere è stato molto tempo fa, forse è stato risolto.]
La necessità di una ricostruzione è correlata alla ‘immagine base Docker’ di Discourse, che è totalmente disaccoppiata dal numero di versione di Discourse. Ne abbiamo bisogno quando ci sono modifiche critiche alle dipendenze a livello di sistema operativo all’interno dell’immagine docker.
Quindi sarebbe complicato includerlo nelle note di rilascio principali di Discourse. Ma capisco la tua frustrazione nel non essere in grado di aggiornare dall’interfaccia utente. Forse possiamo apportare dei miglioramenti all’interfaccia utente in quel senso.
Potrei immaginare che ciò funzioni tramite:
Detto questo, al momento abbiamo altre questioni più importanti da affrontare per il lavoro di versioning in generale (ad esempio, la compatibilità dei componenti tema/plugin).
Oh, penso che non essere sempre in grado di usare l’interfaccia utente per aggiornare vada bene e chiunque (individuo, azienda, qualunque cosa) che auto-ospita Discourse deve (dovrebbe) avere qualcuno disponibile con almeno competenze di amministrazione di base del server per essere in grado di eseguire attività come mantenere aggiornato il sistema host e ricostruire Discourse.
Le cose più importanti secondo me sono:
Finché l’interfaccia utente si aggiorna sempre correttamente dopo l’aggiornamento di Docker_manager, ovvero non si arriva in uno stato in cui sa che Docker_manager è aggiornato ma non sa che è necessaria una ricostruzione, penso che entrambe queste condizioni siano già vere.