Non esiste una definizione formale di “verificato” di cui sono a conoscenza.
Tutto il software è potenzialmente difettoso.
tests-passed ha i commit più aggiornati. beta riceve solo rilasci beta. stable riceve solo rilasci stabili.
tests-passed è ciò che è in esecuzione su quasi tutti i siti ospitati su discourse.org e sulla stragrande maggioranza dei siti self-hosted.
@mcwumbly – abbiamo un documento “quale versione dovrei eseguire”? Ho cercato un po’ e non ne ho trovato uno. Tutto ciò che ricordo è qualcosa di simile da annunci stable.
Concordo che dovremmo avere un argomento migliore su cui possiamo fare più chiaramente riferimento alla nostra raccomandazione di essere su tests-passed.
Separatamente, sono alquanto tentato di eliminare beta (potrei avviare un nuovo argomento al riguardo).
Ho separato questo (penso sia la prima volta che lo faccio!), poiché la povera anima ancora non riesce a capire se sia “pericoloso” aggiornare, e questa discussione su come risolvere il problema delle persone che non sanno se aggiornare non sta aiutando.
L’altra cosa che ha chiesto, da cui è partito, e che penso sia abbastanza ragionevole, è “Se sono sull’ultima beta, perché dovrei aggiornare?” E quanto sopra lo affronta abbastanza direttamente.
Non credo che dovremmo farlo. Vogliamo che le persone utilizzino tests-passed. Le istruzioni di installazione ufficiali dovrebbero portare a un’installazione predefinita con quante più impostazioni possibili corrispondenti a ciò che desideriamo. Ciò include il branch che viene tracciato.
Ci saranno sempre persone che decideranno di utilizzare, ad esempio, l’ultima versione stabile. Non avere una guida su come ottenerla nel posto più intuitivo non farà sparire quelle persone; renderà solo le cose un po’ meno convenienti per loro - e probabilmente a volte significherà che verranno qui a chiedere, e altri passeranno del tempo a rispondere alla domanda (ancora e ancora).\n\nProbabilmente l’argomento più forte, tuttavia, è che la guida può mostrare loro come farlo correttamente, il che significa che potranno tornare indietro in seguito se cambieranno idea. Se non lo sanno, potrebbero finire per rompere la loro installazione, il che sarà scomodo sia per loro che per la loro comunità.\n\nSe INSTALL-cloud.md ha una sezione su come cambiare branch, può chiarire qual è l’impostazione predefinita e perché, rendendo chiaro che l’impostazione predefinita è la più utilizzata e la più facile da supportare.
Sono felice al 100% che ci sia una guida su Meta su come cambiare branch. Semplicemente non penso che appartenga alla guida di installazione ufficiale, dove al 95% delle persone non interessa o non ha bisogno di interessarsi.
Se Bob Base sta cercando di installare Discourse, vuole solo completare l’installazione il più rapidamente e facilmente possibile, in modo da poter lavorare sul suo nuovo sito. Le informazioni sul cambio di branch lo faranno solo pensare di più e causeranno confusione.
Ally Avanzata, d’altra parte, potrebbe essere interessata a capire come funzionano i branch e quale sia il migliore per il suo sito. Ma è anche probabile che faccia ulteriori ricerche prima di installare Discourse, non semplicemente scorrendo la guida di installazione.
In effetti, così come stanno le cose, riceviamo occasionalmente argomenti da utenti che desiderano tornare a beta o stabile e che falliscono.
Inserirlo nella documentazione di installazione standard aprirebbe davvero le cateratte, sia a causa di quanto sopra che dei problemi di compatibilità dei plugin con le versioni precedenti.
Sono d’accordo. Nel complesso, sento che beta confonda più le persone di quanto non sia utile.
Penso che aiuti a tracciare una distinzione tra cose che si usano e che hanno un significato interno e cose che significano qualcosa per terzi. Il ramo beta ne è un buon esempio. Sebbene possa avere una qualche utilità interna, ha poca utilità per terzi e talvolta li confonde.
Sarei interessato a sentire il contrario, ma pensandoci ora, non riesco a ricordare un serio self-hoster che utilizzi effettivamente beta in modo significativo. “Basic Bob” non sa davvero cos’è un ramo e probabilmente non gli interessa (e giustamente). “Advanced Ally” userà tests-passed se è un individuo o una PMI, e potrebbe usare stable (o bloccare i commit) se è una media o grande impresa.
Il mio suggerimento sarebbe di mantenere tutto a livello di ramo esattamente come è, ma dire solo pubblicamente “Abbiamo due rami che puoi usare: tests-passed (il predefinito e il migliore) e stable (se sai cosa stai facendo e hai un’esigenza particolare).”
Dal mio punto di vista, basterebbe avere il nome del branch tests-passed visibile accanto al nome della versione sulla dashboard per un miglioramento.
Completamente d’accordo. Chiunque voglia prendere un branch diverso, quasi sempre lo troverà.
Se non riescono a trovarlo con le risorse esistenti (ricerca, progetto GitHub standard), sono davvero dotati delle competenze necessarie per comprendere appieno la differenza tra i branch, tanto meno per discostarsi dalla sicurezza del default?
Certo, ha senso. Ma sento che stiamo perdendo l’opportunità di aiutare le persone a comprendere la distinzione tra le diverse opzioni qui. Non vedo alcun danno nel dire agli auto-hoster che l’impostazione predefinita è tests-passed, che è ideale per la maggior parte dei siti e garantisce di ricevere le ultime correzioni di sicurezza e aggiornamenti. Se sei avverso al rischio, puoi lasciare l’impostazione su tests-passed e aggiornare solo quando ti viene richiesto nel software, o circa una settimana dopo aver ricevuto la richiesta. In questo modo, altre persone scopriranno prima eventuali problemi e questi verranno risolti prima che tu aggiorni.
Dato quanto sopra, ci sono ragioni legittime per cui gli auto-hoster dovrebbero passare da tests-passed? Immagino che se il tuo sito è pesantemente modificato e si romperà se il core di Discourse o i plugin ufficiali vengono aggiornati, e non ti fidi di te stesso o dei tuoi amministratori a non aggiornare? O se stai configurando un ambiente di sviluppo o di staging?
Un altro posto dove spiegare questo potrebbe essere in app.yml, che attualmente è piuttosto criptico perché si riferisce solo a tests-passed e non menziona le opzioni o quando potresti passare a un’altra.
## Quale revisione Git dovrebbe utilizzare questo container? (predefinito: tests-passed)
#version: tests-passed
Secondo me, usare qualcosa di diverso da tests-passed ha senso solo se sei su un servizio di hosting gestito o: 1) se hai un team che gestisce la tua community (cioè, sei una media o grande impresa); e 2) hai un motivo specifico per non essere su tests-passed, ad esempio hai più personalizzazioni che potrebbero rompersi.
Direi che entrambe le condizioni sono necessarie, perché a meno che tu non abbia un team che gestisce la tua community nello scenario di personalizzazioni multiple fragili, il tuo problema non è l’uso del tuo branch, ma la gestione generale del tuo sito (cioè, non è sostenibile).
Anche se entrambe le condizioni sono vere, ci sarebbero altre cose da considerare prima, come la tua politica di aggiornamento.
Penso che il problema sia che se dicessi qualcosa come “Puoi usare stable o tests-passed”, alcune persone inserirebbero stable perché suona “sensato” quando probabilmente non dovrebbero usarlo.
Dove va il beta?
Per rafforzare il caso contro il branch beta, in vari contesti scritti e parlati le principali confusioni che produce sono:
Le persone associano normalmente il termine “beta” a qualcosa di più all’avanguardia rispetto allo “standard”. Non è il caso qui.
Alcune aziende considerano di usarlo perché sembra un po’ meno all’avanguardia di tests-passed e un po’ più aggiornato di stable, cioè, di nuovo, sembra “sensato”. Ma nella maggior parte dei casi non è una buona idea.
“beta” è un termine usato sia nei numeri di versione di Discourse che come nome di branch di Discourse. Ho scoperto che questo confonde alcune persone.
“Beta” probabilmente scoraggia alcune persone semi-alfabetizzate al computer come me: il significato usuale è “ancora in fase di test per la qualità” piuttosto che “ancora in fase di aggiunta di funzionalità”.
Suppongo che stia pensando principalmente ai nomi delle versioni piuttosto che al nome del ramo. Avevo ipotizzato di essere su un ramo “beta” basandomi sui nomi delle versioni (non lo sono) fino a quando non ho controllato ora, quindi nulla mi ha scoraggiato…
Sì. Penso che sia confusionario (o posso vedere come potrebbe essere confusionario) che tu sia su tests-passed e la versione venga visualizzata come “beta”, ma puoi eseguire un aggiornamento e ottenere nuovo codice che è la stessa versione beta su cui ti trovi già. E ci sono settimane e centinaia di commit tra le release beta.
