Mi chiedo se possiamo dare ai plugin un numero di versione per consentire all’elenco dei plugin di specificare la versione minima e massima con cui è compatibile.
In questo modo non ci troveremo nella situazione in cui il nostro plugin viene aggiornato, ma la nostra versione di discourse è indietro e questo interrompe l’intero sito.
Ci sono due ampie categorie di plugin e TC:
I plugin ufficiali mantengono già la compatibilità e, se non sono compatibili, di solito c’è uno sviluppatore stipendiato che risolve i problemi entro pochi giorni.
È già abbastanza difficile per i manutentori mantenere la compatibilità, figuriamoci tenere traccia se lo sono o meno.
Ci sono solo due versioni pratiche da mantenere:
stable più recentetests-passed più recenteÈ già possibile utilizzare il sistema di pinning (Pinning plugin and theme versions for older Discourse installs (.discourse-compatibility)) per stable. Potrebbe essere utile mostrarlo in qualche modo per indicare una compatibilità esplicita, ma non significa che il plugin non sia compatibile se non c’è un pin.
La compatibilità con l’ultima versione potrebbe essere indicata con un segno di spunta verde dal CI su GitHub.
Ciò si basa su due cose:
Quest’ultima è una grande richiesta per i manutentori di terze parti che fanno le cose gratuitamente.
Per i plugin non ufficiali, la tua richiesta di funzionalità si riduce a un finanziamento adeguato dei plugin di terze parti.
Come autore di plugin esperto che ha visto di tutto, posso dirti che è quasi impossibile finanziare plugin di terze parti.
L’unico motivo per cui i miei plugin funzionano ancora è perché:
Questo è prezioso per me, ma ha dei limiti.
Direi che lo sviluppo di plugin di terze parti è vicino a 
nell’ecosistema Discourse, con solo una piccolissima manciata di sviluppatori in grado di mantenere le cose funzionanti contro la velocità molto esigente del core.
Altre eccezioni:
Dato che puoi fare affidamento solo sui plugin ufficiali per la compatibilità (e forse su una manciata di altri da sviluppatori molto attivi come me o Communiteq), ti suggerisco di concentrarti semplicemente sull’utilizzo dei plugin official e per questi ritengo che la tua richiesta di funzionalità sia ridondante perché esiste un processo per tenere traccia del core.
Non sono sicuro di come definire una versione massima compatibile per un plugin. Un plugin semplice potrebbe probabilmente dire che funziona almeno fino alla versione 4.0 e, quando arriverà la 4.0, potrebbe ancora funzionare perché CDCK non ha introdotto modifiche che rompono la compatibilità.
Ma forse il plugin semplice ha utilizzato qualcosa che CDCK ha deprecato nella versione 3.8 e rimosso nella versione 3.10… Abbastanza difficile tenerne conto.
Perché non puoi.
Sarà obsoleto non appena verrà rilasciato il prossimo commit.
Ma è semplice:
Quindi controlla il segno di spunta verde prima di installare.
Ci ho giocato e ho trovato una soluzione su Github.
Quindi un semplice segno di spunta verde per l’ultimo job CI non è abbastanza buono, poiché le cose potrebbero essere cambiate di recente, il che potrebbe rompere il plugin. Fondamentalmente è necessario rieseguire i job CI quando Discourse aggiorna i branch.
In questo repository di esempio ho elaborato una soluzione efficiente. Si tratta fondamentalmente di un workflow pianificato che controlla i branch importanti del repository Discourse per vedere se ci sono cambiamenti, se ci sono attiverà il normale workflow CI che dovrebbe eseguire la suite di test. Nel tuo readme puoi quindi inserire alcuni badge per mostrare come i workflow CI sono stati eseguiti rispetto alle modifiche più recenti.
Il workflow di monitoraggio viene eseguito in pochi secondi. Quindi, quando pianificato, consumerebbe solo 1 minuto di tempo di azione di GitHub.
Ovviamente l’affidabilità di tutta questa configurazione dipende dallo sforzo dello sviluppatore del plugin/componente tema nel creare una buona suite di test.
E hai ancora il problema dell’UX che dalla pagina “aggiorna” di Discourse non sai se l’ultimo job CI è fallito per una versione specifica.
Quindi, oltre ad avere un workflow di monitoraggio che ricostruisce un plugin quando il branch Discourse cambia, è necessario creare un artefatto di build che registri il risultato (pass/fail). Nei metadati del tuo plugin dovresti essere in grado di puntare a questo artefatto, e Discourse dovrebbe recuperare questo artefatto per visualizzare la compatibilità/risultato nell’interfaccia di aggiornamento.
Non è una costruzione infallibile, ma è qualcosa.
Ecco perché ho scritto “ad ogni nuovo commit del core in CI” 
Abbiamo avuto per molto tempo una dashboard su Pavilion che faceva esattamente tutto questo.