Release cycle pt BR

Ciclo de lançamento

O ASF usa uma versão comum do C# com 4 números, escritos como A.B.C.D. Cada versão é sempre "congelada" e aponta para um código fonte fixo do qual foi compilada (que vem com o lançamento). Não pretendemos remover nenhuma versão publicada anteriormente, desde que nosso provedor de hospedagem (GitHub) continue permitindo sua preservação por tempo indefinido. Portanto, você pode reverter com segurança para qualquer uma delas sem a necessidade de fazer cópias próprias.

Quanto à versão do ASF, estamos fazendo o melhor para seguir o padrão MAJOR.MINOR.PATCH do semver nos 3 últimos números - B.C.D. Esses três números estão diretamente relacionados ao código do ASF. O número mais significativo A indica mudanças com um escopo que vai além de apenas o código do ASF em si, geralmente afetando diretamente a base do programa.

O ASF, como projeto, tem como objetivo de **lançar aproximadamente uma nova função por mês **, indicado pelao incremento do número C. Para tornar essa versão possível temos pré-lançamentos menores dedicados a usuários avançados, que servem como marcos menores para as mudanças que são lançadas conforme necessário, quando houver mudanças suficientes desde o último pré-lançamento para se concentrar. Eventualmente, quando um pré-lançamento final for determinado como estável e maduro o suficiente, sem regressões críticas conhecidas que devam ser corrigidas em comparação com o lançamento estável anterior, ele será promovido para o novo lançamento estável, ao mesmo tempo em que abre um novo ciclo mensal para o próximo.

Embora façamos o nosso melhor para garantir que até mesmo nossos pré-lançamentos sejam relativamente estáveis, é importante notar que os pré-lançamentos devem ser cuidadosamente avaliados ao serem executados em qualquer ambiente de produção. Pré-lançamentos podem ter erros críticos e funcionalidades problemáticas, e é exatamente por isso que as liberamos nesse estado - para que possamos evitar qualquer tipo de problemas em nossas compilações estáveis e oferecer um software confiável. Se você estiver relutante em aceitar o alto risco de usar um software potencialmente instável, por favor, evite usar nossas compilações de pré-lançamento e fique com a versão mais recente e estável, que é mais adequado para a maioria dos usuários.

Dependendo da quantidade de mudanças no ciclo, geralmente haverá um único incremento na versão C (a partir da versão estável anterior) e incrementos na versão D para cada pré-lançamento, conforme necessário. No entanto, ao introduzir mudanças de escopo muito maior, especialmente mudanças drásticas, o ciclo pode começar a partir de (ou mudar no meio para) um incremento B ou até mesmo A. Essa mudança indica que o ciclo de lançamento atual tem potencial para ser mais instável do que o usual e deve ser testado com cuidado. Lembre-se de que as mudanças no semver que estamos fazendo se referem apenas à versão estável lançada anteriormente. Não acompanhamos a versão entre os próprios pré-lançamentos em um ciclo, o que significa que a versão 1.0.1.2 pode ter um novo recurso que a 1.0.1.1 não tinha, desde que a versão estável marcada anteriormente pertença à família 1.0.0.X. Desse jeito, pode haver grandes mudanças mesmo em dois pré-lançamentos do mesmo ciclo, o que acontece geralmente quando ainda estamos decidindo sobre a forma final de funcionalidades recém-introduzidas ou similares.

Incremento de versão	Semver	Exemplo de alterações
A		Grandes mudanças no runtime do .NET, alterações na base, mudanças drásticas que vão além do código do ASF, coisas que podem até "devorar seu gato"
B	Maior	Mudançãs menores no tempo de execução .NET, mudanças grandes no código base do ASF, mudanças no código que não se classificam como menores
C	Menor	Novos ciclos mensais, geralmente introduzindo novas funcionalidades, comandos, propriedades de configuração ou outras alterações que não modifiquem as configurações existentes
D	Patch	Pré-lançamentos que fazem parte do ciclo existente (indicado por um número mais significativo), correções críticas de bugs para lançamentos estáveis já existentes que não introduzem alterações de código além do necessário

Note que funcionalidades e mudanças recém implementadas podem demorar a ter documentação (por exemplo, na wiki), já que a documentação geralmente é escrita quando o código final de determinada funcionalidade está pronto (para nos poupar o tempo de reescrever a documentação toda vez que decidirmos mudar a funcionalidade na qual estamos trabalhando). Devido ao fato de que pré-lançamentos podem conter trabalho em progresso no código que ainda não tem uma forma final, a documentação deverá ser escrita no último estágio do desenvolvimento. O mesmo se aplica ao relatório de mudanças que pode ser indisponível para determinado pré-lançamento até um tempo depois. Portanto, se você decidir usar versões de pré-lançamento, esteja preparado para olhar as commits do ASF de vez em quando. Claro, a falta de documentação se aplica apenas aos pré-lançamentos; toda versão estável deve sempre ter um relatório completo de mudanças e documentação no wiki no momento em que está sendo lançado.

O relatório de mudanças preciso que compara uma versão a outra está sempre disponível no GitHub através de commits e alterações de código. No lançamento, nós tendemos a documentar apenas as alterações que consideramos importantes entre a última versão estável e o lançamento atual. Essa nota de alterações resumida nunca é completa. Caso queira ver todas as mudanças que ocorreram entre uma versão e outra (como as atualizações de nossas dependências), use o comparador do GitHub para isso.

O projeto ASF é distribuído pelo nosso processo de integração contínuo. Cada build deve ser reproduzível, então não deve haver problema em obter o código-fonte (incluído no lançamento) de uma determinada versão e compilá-lo você mesmo, obtendo o mesmo resultado que o disponível em nossos binários pré-compilados. Normalmente evitamos compilar os lançamentos manualmente. Enquanto os sistemas estiverem operacionais, os binários lançados vêm diretamente do nosso processo de CI.