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 curtida
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 curtidas
There is a high level release note list here: Discourse Version 2.1
1 curtida
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 curtidas
Esta postagem foi atualizada pela última vez 2021-06-28T04:00:00Z para detalhar os processos atuais.
Olá a todos! Temos vários tópicos para abordar aqui, vamos ver se consigo cobri-los todos.
Essa é uma decisão intencional da nossa parte. Não temos um sistema formal de lançamento para nossas versões beta. Lançamos uma nova versão quando faz sentido para nós. Como tal, geralmente há pouco aviso antes de um lançamento e, portanto, não há muito tempo para escrever as notas de lançamento. O @codinghorror decidiu que não fazia sentido atrasar um lançamento para esperar que as notas estivessem prontas.
As versões beta agora são coordenadas entre as equipes de engenharia e comunidade. As notas de lançamento devem estar ao vivo no mesmo momento das versões beta, se não pouco antes.
Você não verá notas de lançamento para a beta1. Para evitar confusão, as notas de lançamento são escritas para todas as versões beta. As versões estáveis também receberão notas. Note que a beta1 (de qualquer versão) é praticamente idêntica à última beta da versão anterior.
Para entender o motivo disso, preciso explicar um pouco sobre como nossas branches são configuradas.
Para nossos propósitos aqui, precisamos saber sobre 4 branches do Discourse: main, tests-passed, beta e stable.
Main:
Quando um novo commit é adicionado ao Discourse, ele está na branch main. A main é a branch mais recente (mais atual) do Discourse e não recomendamos que ninguém execute seu site rastreando a branch main.
Tests-passed:
Quando um novo commit é enviado para a branch main, nosso servidor de build executa automaticamente todos os nossos testes contra o código mais recente. Assim que todos passam, o commit é adicionado à nossa branch tests-passed. Esta é a branch que todos os sites do Discourse executam por padrão.
Beta:
A cada poucas semanas, enviamos os commits atuais da tests-passed para a beta. Usamos a beta como um “marco” para distribuir uma coleção de commits que queremos que mais sites executem e testem. Também enviamos uma beta se tivermos uma correção de segurança importante que queremos que os sites recebam. Quando uma beta é enviada, todos os sites executando em tests-passed ou beta recebem o e-mail “nova atualização disponível”. Sites executando tests-passed atualizarão para os commits atuais da tests-passed (incluindo quaisquer novos commits enviados após a beta), enquanto aqueles na beta não.
Stable:
A cada 4 a 6 meses, lançamos uma nova build stable. Cerca de 2 semanas antes de enviar a stable, lançamos nossa última beta. Em seguida, monitoramos nossos logs de perto para tentar capturar quaisquer bugs remanescentes que existam e evitar adicionar novos recursos ou mudanças arriscadas. Assim que ficamos satisfeitos com o estado da beta atual, enviamos para a stable.
Compreendendo o acima, vamos usar a 2.0.0 como exemplo. Enviamos a 2.0.0.beta10 em 16 de maio. Todos os usuários executando tests-passed ou beta receberam um e-mail (e assumimos que atualizaram). Escrevi notas de lançamento para aquela beta. Cerca de 2 semanas depois, em 31 de maio, enviamos aquela build para a stable como 2.1.0. Para garantir que os usuários executando em tests-passed ou beta também recebam a atualização, enviamos a mesma build como 2.1.0.beta1.
Isso tudo faz sentido? Há algo que eu pudesse fazer de forma diferente com o release-notes em #feature:announcements para tornar isso mais claro?
20 curtidas