Discourse non rilascia una versione LTS

Generale
1

Non ero a conoscenza della compatibilità con discourse, quindi è qualcosa su cui dovrò informarmi.

Vorrei affrontare questo punto, perché sembra che ci sia un’enorme discrepanza tra il modo in cui il team di Discourse pensa allo stabile e il modo in cui il resto della community di discourse/la più ampia community di amministratori di forum pensa all’offerta stabile di Discourse.

Motivi chiave per cui lo stabile non soddisfa la definizione di LTS.

1) Lo stabile viene attivamente sconsigliato dallo staff ogni volta che viene menzionato

Non voglio necessariamente chiamare singoli utenti, ma ecco una selezione di post dello staff per mostrare il tema:

Si noti che per certi versi tests-passed è più stabile di stable in quanto è ciò che discourse.org esegue, quindi è il più testato.

Quindi Discourse è in uno stato di beta perpetua, il che significa che stiamo sempre lavorando su nuove funzionalità e miglioramenti. Nel nostro caso beta non significa instabile; ospitiamo siti con milioni di visualizzazioni di pagine mensili sulle nostre versioni tests-passed e beta.

Il canale stabile non è necessariamente più “stabile” di tests-passed. Si tratta più dell’idea che i bug sono noti e serve come punto di controllo per un determinato set di funzionalità e miglioramenti. Con tests-passed, potrebbero esserci nuovi bug introdotti, poi corretti qualche commit dopo.

Il messaggio è stato piuttosto coerente sul fatto che Discourse è in ‘beta perpetua’, che non è l’esperienza che gli utenti di produzione / non sviluppatori vogliono avere.

In una rapida ricerca su duckduckgo dei primi dieci link per discourse stable, nessuno di essi sembra effettivamente sostenere l’uso dello stabile. Quindi, indipendentemente dalla sua qualità effettiva, se lo staff guida universalmente le persone lontano dallo stabile, ciò crea un’impressione negativa nelle menti delle persone riguardo alla sua idoneità allo scopo.

Lo stabile potrebbe essere ottimo, ma se ci viene detto ripetutamente che è meglio non usarlo, non lo considereremo per implementazioni serie.

2. Un LTS riceve correzioni di bug oltre alle sole correzioni di bug di sicurezza

Un LTS è qualcosa che non riceve aggiornamenti di funzionalità, ma riceve correzioni di bug. Secondo i commenti dello staff, in Discourse non sembra esserci alcuno sforzo per riportare le correzioni di bug per problemi non di sicurezza. Forse non è vero, ma questo è ciò che ci è stato detto.

3. Un LTS ha passaggi di installazione semplici

La guida all’installazione non menziona nemmeno l’esistenza dello stabile.

4. Un LTS è ampiamente utilizzato

Prima del tuo post, non avevo sentito parlare di un uso diffuso del ramo stabile. Viene anche utilizzato ampiamente in produzione? Dato quanto è nascosto, ne dubito, ma non ho metriche per dirlo. Questo è un fattore importante perché dà alle persone la fiducia di utilizzare lo stabile per le loro implementazioni di produzione.

5. Un LTS ha un ciclo di rilascio chiaro e note di aggiornamento

Non vedo una posizione centrale in cui lo stabile sia chiaramente documentato. (Potrei semplicemente non trovarla!)

Le mie aspettative per un LTS sono una pagina che descriva:

  • Versione di rilascio attiva corrente
  • Note di rilascio includendo:
    • Modifiche/funzionalità principali tra le versioni LTS
    • Passaggi di migrazione dalla versione LTS precedente (soprattutto modifiche che rompono la compatibilità a cui prestare attenzione)
    • Durata del supporto attivo pianificata per ciascuna versione

es: mediawiki, ma in realtà qualsiasi LTS open source importante ha pagine simili.

Questa documentazione mi aiuta a pianificare quando ci sarà una modifica che rompe la compatibilità e richiederà tempi di inattività e/o intervento manuale.

6. Un LTS non ha modifiche che rompono la compatibilità importanti all’interno di un ciclo di rilascio

Questo potrebbe benissimo essere il caso dello stabile, ma sono troppo abituato a premere il pulsante di aggiornamento e il forum va offline per saperlo con certezza. Immagino che quello che sto cercando qui siano avvisi più chiari quando si passa da versioni che rompono qualcosa.

7. Un LTS fornisce avvisi di deprecazione delle API per almeno un ciclo di rilascio LTS completo

Questi dovrebbero essere misurati con un ritmo di un anno o più, anziché di un mese o più.

8. Un LTS è pianificato / ha periodi di supporto sovrapposti

Qualsiasi LTS di grandi dimensioni avrà un periodo di supporto sovrapposto tra due versioni LTS. Lo stabile sembra semplicemente fare un’inversione binaria alla versione successiva. (La mia impressione potrebbe anche essere errata a causa della mancanza di una pagina di documentazione centrale)

9. È semplice aggiornare da non-LTS a LTS

Non è necessario supportare il ritorno indietro, ma quando è disponibile un LTS, non è chiaro come passare in modo pulito ai rami LTS. Sembra che ci siano alcuni post nel forum al riguardo, ma di nuovo, nessuna documentazione centralizzata che ho potuto trovare.

Sono un fan di Discourse, ma questo è un punto dolente comune sia per me che per molte altre persone. Quello che lo stabile è al momento è solo un ramo, non un LTS.

4 Mi Piace
2

Spostato questo in un argomento separato, sembra non correlato al raggruppamento dei plugin.

3 Mi Piace
3

Se consideriamo la faccina triste nella dashboard di amministrazione rispetto a essere così tanti commit indietro in “aggiorna discourse”
la parte di aggiornamento critico fa parte di tests-passed e se fai “Aggiorna tutto” prontamente dopo che la faccina felice diventa triste, sarai in sincronia con tests-passed

4

Penso che questo specifico aggiornamento richieda la ricostruzione dalla console. Due volte.

1 Mi Piace
5

Discourse sembra avere una velocità piuttosto elevata in termini di modifiche e una roadmap ambiziosa.

Per supportarla ha bisogno di molti feedback dagli utenti. Penso che ci sia una chiara strategia implicita per promuovere tests-passed perché supporta il feedback precoce sulle nuove modifiche.

In cambio, l’utente ottiene software gratuito e nuove funzionalità. È una sorta di patto. Penso che nel tempo questo accordo si sia dimostrato un successo.

La build stabile non aiuta molto lo sviluppo, quindi potrebbe non essere nell’interesse commerciale promuoverla così tanto (solo la mia opinione, non parlo affatto per CDCK).

L’altro problema con la versione stabile è questo, ed è ancora più significativo:

Di solito ci sono molte modifiche tra le versioni stabili, incluse deprecazioni significative e modifiche API. Essere coinvolti in tests-passed come sviluppatore, amministratore di sito o creatore di temi ti dà la possibilità di affrontare le modifiche in piccoli pezzi gestibili, invece di avere un’enorme montagna da scalare ogni volta che raggiungi la prossima pietra miliare stabile.

Per supportare questi grandi salti, probabilmente avrai bisogno di un sito di staging e di una serie di casi di test da eseguire.

Se non possiedi personalizzazioni, potresti optare per la versione stabile, ma ti affidi pesantemente ad altri su cui potresti non avere una forte influenza per garantire che i componenti aggiuntivi che stai utilizzando siano sufficientemente mantenuti per il tuo prossimo aggiornamento. Potresti scoprire che alcuni elementi perdono il supporto al momento dell’aggiornamento e a quel punto potresti trovarti in difficoltà. Potresti anche scoprire che lo sviluppatore non supporta affatto la versione stabile e potresti dover creare un fork e preparare un “taglio” del plugin per supportare la tua build stabile. (tuttavia, c’è un buon sistema di pinning in atto, quindi non è un lavoro enorme)

L’altro aspetto significativo di Discourse è che è molto intensivo nei test unitari, quindi il ramo test-passed è solitamente molto buono dal punto di vista della stabilità.

4 Mi Piace
6

Dato il rifiuto del management di annullare modifiche impopolari come il bundling dei plugin, non penso che questa parte sia accurata. Forse da una prospettiva QA, ma anche in quel caso ho avuto diversi bug piuttosto difficili che non sono stati risolti in passato. Alla fine, mi rendo conto che sono loro quelli che investono tempo e denaro, quindi possono prendere le loro decisioni, ma secondo me non credo che sia una strategia per ottenere più feedback.

Penso che la ragione più realistica per cui non supportano una LTS adeguata sia che costerebbe a qualcuno del team tempo per gestirla/documentarla. È una funzionalità che avvantaggia principalmente gli self-hoster, quindi immagino che sarebbe considerata una perdita di tempo per loro. Ma è una funzionalità piuttosto attesa e non averla è un vero svantaggio quando gli amministratori di forum scelgono il loro software per forum, poiché altri contemporanei hanno offerte più stabili.

7

Al contrario, penso che il raggruppamento dei plugin serva proprio a promuoverne l’uso e, di conseguenza, a ottenere maggiori feedback.

8

La direzione ha specificamente segnalato problemi con la discrepanza delle versioni che influiscono sulla produttività del team di sviluppo nell’altro thread. Il che è una motivazione valida, ma non il modo ideale per risolvere il problema alla radice, come discusso nell’altro thread.