When I get that “New Discourse version, update available” email from my forum (this time about 2.1.0.beta1), I know @jomaxro 's elaborate release notes will appear here within 6-24 hrs. or so. It’s not very important, but I would organize it in a different order.
1 Mi Piace
I agree, first thing I do is go and look at the release notes to determine whether or not I am going to apply the update.
2 Mi Piace
There is a high level release note list here: Discourse Version 2.1
1 Mi Piace
The notes are in the above topic, so this is covered.
I’m not seeing any notes specifically for 2.1b1. Just a general list of goals for the final version of 2.1.
I’m off today (family event), will respond to this properly next week. Short version: there are no major changes from the last release notes (2.0.0.beta10) and 2.1.0.beta1 - we simply pushed 2.0 to stable and moved work to 2.1.
4 Mi Piace
Questo post è stato aggiornato l’ultima volta 2021-06-28T04:00:00Z per descrivere i processi attuali.
Ciao a tutti! Ci sono diversi argomenti da affrontare qui, vediamo se riesco a coprirli tutti.
Questa è una decisione intenzionale da parte nostra. Non abbiamo un sistema di rilascio formale per le nostre versioni beta. Pubbliciamo una nuova versione quando riteniamo opportuno farlo. Di conseguenza, c’è generalmente poco preavviso prima di un rilascio e, quindi, poco tempo per scrivere le note di rilascio. @codinghorror ha deciso che non aveva senso bloccare un rilascio in attesa che le note fossero pronte.
Le versioni beta sono ora coordinate tra i team di ingegneria e community. Le note di rilascio dovrebbero essere online nello stesso momento delle versioni beta, se non poco prima.
Non vedrete note di rilascio per la beta1. Per evitare confusione, le note di rilascio vengono scritte per tutte le versioni beta. Anche le versioni stabili riceveranno delle note. Si noti che la beta1 (di qualsiasi versione) è praticamente identica all’ultima beta della versione precedente.
Per capire il motivo di ciò, devo spiegare un po’ come sono configurati i nostri rami.
Per i nostri scopi qui, dobbiamo conoscere 4 rami di Discourse: main, tests-passed, beta e stable.
Main:
Quando viene aggiunto un nuovo commit a Discourse, si trova sul ramo main. Main è il ramo assoluto più recente (più attuale) di Discourse e non consigliamo a nessuno di far funzionare il proprio sito seguendo il ramo main.
Tests-passed:
Quando un nuovo commit viene spinto sul ramo main, il nostro server di build esegue automaticamente tutti i nostri test sull’ultimo codice. Una volta che tutti superano, il commit viene aggiunto al nostro ramo tests-passed. Questo è il ramo su cui tutti i siti Discourse vengono eseguiti per impostazione predefinita.
Beta:
Ogni poche settimane spingiamo i commit attuali su tests-passed su beta. Usiamo beta come un “traguardo” per distribuire una raccolta di commit che vogliamo che più siti eseguano e testino. Spingiamo anche una beta se abbiamo una correzione di sicurezza importante che vogliamo che i siti ricevano. Quando una beta viene spinta, tutti i siti in esecuzione su tests-passed o beta ricevono l’email “nuovo aggiornamento disponibile”. I siti in esecuzione su tests-passed si aggiorneranno ai commit attuali di tests-passed (inclusi eventuali nuovi commit spinti dopo la beta), mentre quelli su beta non lo faranno.
Stable:
Ogni 4-6 mesi rilasciamo una nuova build stable. Circa 2 settimane prima di spingere la stable, rilasciamo la nostra ultima beta. Quindi osserviamo attentamente i nostri log per cercare di catturare eventuali bug residui ed evitare di aggiungere nuove funzionalità o modifiche rischiose. Una volta soddisfatti dello stato della beta corrente, spingiamo su stable.
Capendo quanto sopra, usiamo 2.0.0 come esempio. Abbiamo spinto 2.0.0.beta10 il 16 maggio. Tutti gli utenti in esecuzione su tests-passed o beta hanno ricevuto un’email (e assumiamo che abbiano aggiornato). Ho scritto le note di rilascio per quella beta. Circa 2 settimane dopo, il 31 maggio, abbiamo spinto quella build su stable come 2.1.0. Per garantire che anche gli utenti in esecuzione su tests-passed o beta ricevano l’aggiornamento, abbiamo spinto la stessa build come 2.1.0.beta1.
Ha tutto senso? C’è qualcosa che potrei fare diversamente con release-notes in #feature:announcements per rendere tutto più chiaro?
20 Mi Piace