Release cycle pt PT

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, apontando para um código fonte fixo do qual foi feito (agrupado junto com o lançamento). Não pretendemos remover nenhuma versão anteriormente publicada, desde que nosso provedor de hospedagem (GitHub) continue bem com a preservação deles para um futuro indefinido, para que você possa voltar com segurança para qualquer um deles sem necessidade de fazer auto-cópias.

In general in terms of ASF versioning, we're doing our best to follow semver versioning of MAJOR.MINOR.PATCH on the 3 least significant numbers - B.C.D. Esses três números são diretamente relacionados ao código do ASF. O número mais significativo A indica mudanças com um escopo que normalmente vai além da base de código do ASF em si, Muitas vezes, afecta directamente a fundação do programa.

O ASF como projeto tem como objetivo ter mais ou menos uma versão de recursos por mês, indicado por um número de C. Para tornar essa versão possível, temos menores pré-lançamentos dedicados aos usuários avançados. que servem como marcos mais pequenos de mudanças que são lançadas conforme a necessidade, quando haverá mudanças suficientes desde a última versão para se concentrar. Finalmente, quando um pré-lançamento final será determinado a ser estável e maduro o suficiente, sem regressões críticas conhecidas que devem ser corrigidas em comparação com o lançamento estável anterior, será promovido para a nova versão estável, ao mesmo tempo em que abrirá um novo ciclo mensal para o próximo.

Enquanto estamos fazendo o nosso melhor para garantir que até mesmo nossos pré-lançamentos sejam relativamente estáveis, deve ser notado que pré-lançamentos devem ser cuidadosamente avaliados quando executados em qualquer ambiente de produção. Pré-lançamentos podem ter bugs críticos e a funcionalidade quebrada de outra forma. é exatamente por isso que estamos liberando-os para começar - para que possamos evitar que tudo isso bagunça em nossas compilações estáveis e oferecer software confiável.

If you're unwilling to accept increased risk that comes from using potentially unstable software, please avoid using our pre-release builds and stick with our latest stable build instead, which is more appropriate for majority of users.

Por outro lado, se você considerar um usuário avançado e quiser ajudar a testar uma nova versão antes que ela esteja pronta para todos - você é mais do que bem-vindo para experimentá-la e fornecer comentários, especialmente em relação a bugs e problemas que de outra forma não existem na versão estável atual.

Dependendo da quantidade de alterações no ciclo, geralmente haverá um único bote de versão C (de stable anterior), e D abunda para cada pré-lançamento na base conforme necessário. No entanto, quando se introduzem mudanças com um âmbito muito maior, especialmente quebrando mudanças, o ciclo pode começar (ou mudar no meio para) B ou até mesmo A - tal mudança indica que o ciclo de lançamento atual tem potencial para ser mais instável do que o normal, e deve ser testado com cuidado.

Tenha em mente que as mudanças semânticas que estamos fazendo se relacionam apenas com a versão estável lançada anteriormente. nós não rastreamos o versionamento dos pré-lançamentos em um ciclo seu, o que significa que a versão 1. .1.2 pode ter uma nova função que 1.0.1. não tinha, enquanto a versão estável marcada anteriormente é da família 1.0.0.X. Da mesma forma, pode haver grandes mudanças de quebra mesmo em dois pré-lançamentos do mesmo ciclo, o que é especialmente verdadeiro quando ainda estamos decidindo sobre a forma final de funcionalidades recém-introduzidas ou similares.

Bomba de versão	Semver	Exemplo de alterações
Um		Muda o grande .NET tempo de execução, mudanças profundas, quebrando as alterações que estão além da base de código do ASF, coisas que podem comer seu gato
B	Principal	Alterações no tempo de execução .NET menor, quebrando mudanças na base de código do ASF, edições de código maiores que vão além da classificação menor
C	Menor	Novos ciclos mensais, geralmente introduzindo novas funcionalidades, comandos, propriedades de configuração ou outras alterações que não quebrem as configurações existentes
D	Atualização	Novos pré-lançamentos que fazem parte do ciclo existente (indicado por um número mais significativo), correções críticas de bugs para versões estáveis existentes que não introduzem alterações de código além do necessário

Por favor, note que recursos e mudanças recém introduzidas podem não estar documentados (por exemplo, na wiki) até algum tempo depois, como a documentação geralmente é escrita quando o código final de determinada funcionalidade está pronto (para nos poupar tempo de reescrever a documentação toda vez que decidirmos modificar a funcionalidade na qual estamos trabalhando atualmente). Devido ao fato de que os pré-lançamentos podem conter trabalho em progresso no código que ainda não tem uma forma final a documentação poderá chegar numa fase posterior do desenvolvimento. O mesmo se aplica ao relatório de mudanças que pode ser indisponível para determinado pré-lançamento até algum tempo depois. Portanto, se você decidir usar os pré-lançamentos, então esteja preparado para olhar o ASF commits de vez em quando. Claro, A falta de documentação se aplica apenas aos pré-lançamentos - cada versão estável deve sempre carregar um relatório completo de mudanças e documentação no wiki no momento em que ele estiver 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 o último lançamento estável e o lançamento atual. Tais mudanças nunca são um relatório completo, então se você gostaria de ver todas as mudanças que aconteceram entre uma versão e outra (como nossas dependências atualizam) - por favor use GitHub Comparação para isso.

O projeto do ASF é fornecido pelo nosso processo de integração contínua. Toda construção deve ser reprodutível, então não deve ser um problema pegar a fonte (incluída no lançamento) de determinada versão e compilar você mesmo recebendo o mesmo resultado que está disponível através de nossos binários pré-compilados. Normalmente, evitamos compilar liberações, contanto que os sistemas estejam operacionais, os binários liberados venham diretamente do nosso processo de CI.