I temi e i componenti nel canale predefinito latest vengono disattivati automaticamente e gli autori dei temi devono ricorrere a workaround poco intuitivi.
Mi sono imbattuto in questo problema qui: Featured Topics - #76 by cogdog È piuttosto controintuitivo che tutte le versioni minime debbano utilizzare un formato come xxx.x.999 inferiore alla versione corrente con cui dovrebbero effettivamente corrispondere.
Piattaforma
Discourse self-hosted sul branch latest
Versione di Discourse: 2026.8.0-latest.1
Riguarda: creazione di temi/componenti del tema (metadati about.json) e controlli di compatibilità dei temi
Descrizione
Risultato effettivo:
Un tema con "minimum_discourse_version": "2026.8.0" nel suo about.json viene considerato non compatibile e disattivato automaticamente quando il sito esegue la build -latest2026.8.0-latest.1. L’unico modo per mantenere il tema abilitato è impostare una versione inferiore, come "minimum_discourse_version": "2026.7.999".
Un problema simile si verifica quando si importa un tema che imposta minimum_discourse_version su un valore in stile -latest (ad es. 2025.12.0-latest), che viene rifiutato come non valido — vedere la segnalazione esistente: 主题配置文件中minimum_discourse_version不支持日期化版本格式
Risultato atteso:
Poiché 2026.8.0-latest.1 è una build -latest della linea di rilascio 2026.8.0, dovrebbe soddisfare un requisito minimo di 2026.8.0. Le build latest sono più recenti della versione rilasciata corrispondente, non più vecchie.
Ma una versione -latest è una versione precedente al rilascio di quella versione. È su questo che si basano le voci di compatibilità da anni.
Il modo in cui hai gestito la cosa con <2026.7.999 sembra controintuitivo, ma perché non hai specificato <2026.8.0-latest?
Se ho bisogno di un commit specifico aggiunto durante lo sviluppo di 2026.8, posso essere sicuro che tutti che usano il rilascio 2026.8 lo hanno, ma non posso essere sicuro che tutti su 2026.8-latest lo abbiano. Forse il loro ultimo aggiornamento è avvenuto prima che il commit specifico venisse aggiunto. Quindi, se 2026.8 includesse 2026.8-latest in modo predefinito, le cose potrebbero rompersi. Penso che sia meglio che l’amministratore debba aspettare qualche settimana prima di poter usare/aggiornare un tema, piuttosto che rischiare che le cose si rompano perché il commit richiesto mancava.
Dovremmo correggere questo problema. Gli autori di temi dovrebbero poter fare:
minimumDiscourseVersion: "2026.8.0-latest"
Tuttavia, come ha menzionato @moin, ciò può essere rischioso poiché -latest si riferisce a un gran numero di commit diversi. Quindi, in un mondo ideale, dovremmo aspettare il prossimo rilascio prima di dipendere da una nuova funzionalità del core da parte di un tema/plugin.
Sento che sia un po’ difficile da capire e che debba usare anche l’approccio x.999 nel file di compatibilità. Ad esempio, ecco come appare attualmente nel mio componente:
2026.7.999: 93b5b22
2026.4.999: 0321b6d
Perché a quanto pare una funzionalità è stata introdotta nella 2026.5.0 e per corrispondere a quella devo inserire 2026.4.999?
Non l’ho usato di recente, ma gli esempi del team di Discourse di solito non usavano la release precedente con .999, bensì la versione corrente con il suffisso -latest.
In passato, sì, quindi ci sono ancora alcuni vecchi temi/plugin che lo fanno (e immagino che umani/robot continuino a copiare il modello legacy).
Ma al giorno d’oggi puoi usare gli indicatori < o > sul lato sinistro del file di compatibilità. Quindi puoi fare
<2026.7.0-latest: 93b5b22
Ma anche, ormai cerchiamo di evitare di usare il file di compatibilità per qualsiasi cosa. Invece ci affidiamo ai rami automatici d-compat/* per gestire la compatibilità con le versioni precedenti.
I documenti su entrambi i modelli, vecchio e nuovo, sono qui: