Compartilhar via

Como o .NET é versionado

O Runtime do .NET e o SDK do .NET adicionam novos recursos em frequências diferentes. Em geral, o SDK é atualizado com mais frequência do que o runtime. Este artigo explica o runtime e os números de versão do SDK.

O .NET lança uma nova versão principal a cada novembro. Versões com numeração uniforme, como .NET 6 ou .NET 8, têm suporte de longo prazo (LTS). As versões LTS recebem suporte e patches gratuitos por três anos. As versões com numeração ímpar têm suporte a longo prazo padrão. As versões de suporte a termo padrão recebem suporte gratuito e patches por 18 meses.

Detalhes de controle de versão

O Runtime do .NET tem uma abordagem major.minor.patch para controle de versão que segue o controle de versão semântico.

O SDK do .NET, no entanto, não segue o controle de versão semântico. As versões do SDK do .NET são liberadas mais rapidamente e seus números de versão devem comunicar tanto o runtime alinhado quanto as versões de patch e a própria versão secundária do SDK.

As duas primeiras posições do número de versão do SDK do .NET correspondem à versão do Runtime do .NET com a qual ele foi lançado. Cada versão do SDK pode criar aplicativos para esse runtime ou qualquer versão inferior.

A terceira posição do número de versão do SDK comunica o número de patch e da versão secundária. A versão secundária é multiplicada por 100. Os dois dígitos finais representam o número do patch. A versão menor 1 e a versão de patch 2 seriam representadas como 102. Por exemplo, aqui está uma possível sequência de números de versão de runtime e SDK:

Alteração Runtime do .NET SDK .NET (*) Anotações
Versão inicial 5.0.0 5.0.100 Versão inicial.
Patch do SDK 5.0.0 5.0.101 O runtime não foi alterado com esse patch do SDK. O patch do SDK incrementa o último dígito no patch do SDK.
Runtime e Patch do SDK 5.0.1 5.0.102 O patch de runtime incrementa o número do patch de runtime. O patch do SDK incrementa o último dígito no patch do SDK.
Alteração do recurso do SDK 5.0.1 5.0.200 O patch de runtime não foi alterado. O novo recurso do SDK incrementa o primeiro dígito no patch do SDK.
Patch de runtime 5.0.2 5.0.200 O patch de runtime incrementa o número do patch de runtime. O SDK não é alterado.

Na tabela anterior, você pode ver várias políticas:

  • O Runtime e o SDK compartilham versões principais e secundárias. Os dois primeiros números de um determinado SDK e runtime devem corresponder. Todos os exemplos anteriores fazem parte do fluxo de versão do .NET 5.0.
  • A versão do patch do runtime só avança quando o runtime é atualizado. O número de patch do SDK não é atualizado para um patch de runtime.
  • A versão do patch do SDK é atualizada somente quando o SDK é atualizado. É possível que um patch de runtime não exija um patch do SDK.

OBSERVAÇÕES:

  • Se o SDK tiver 10 atualizações de recursos antes de uma atualização de recurso em tempo de execução, os números de versão passam para a série 1000. A versão 5.0.1000 seguiria a versão 5.0.900. Não se espera que essa situação ocorra.
  • As versões de patch 99 sem uma versão do recurso não ocorrerão. Se uma versão se aproximar desse número, ela forçará uma versão do recurso.

Você pode ver mais detalhes na proposta inicial no repositório dotnet/designs .

Versionamento semântico

O Runtime do .NET se adere ao SemVer (Controle de Versão Semântico), adotando o uso do controle de versão do MAJOR.MINOR.PATCH, usando as várias partes do número de versão para descrever o grau e o tipo de alteração.

MAJOR.MINOR.PATCH[-PRERELEASE-BUILDNUMBER]

As partes opcionais PRERELEASE e BUILDNUMBER nunca fazem parte de versões com suporte e só existem em compilações noturnas, compilações locais de componentes de origem e versões de prévia não suportadas.

Alterações no número de versão do runtime

  • MAJOR é incrementado uma vez por ano e pode conter:

    • Alterações significativas no produto ou uma nova direção do produto.
    • A API introduziu alterações significativas. Há um alto padrão para aceitar alterações interruptivas.
    • Uma versão mais recente MAJOR de uma dependência existente é adotada.

    As versões principais ocorrem uma vez por ano, versões com números pares são lançamentos LTS (com suporte de longo prazo). A primeira versão do LTS usando esse esquema de controle de versão é o .NET 6. A versão não LTS mais recente é o .NET 9.

  • MINOR é incrementado quando:

    • Uma área de superfície de API pública é adicionada.
    • Um novo comportamento é adicionado.
    • Uma versão mais recente MINOR de uma dependência existente é adotada.
    • Uma nova dependência é introduzida.

  • PATCH é incrementado quando:

    • Correções de bug são feitas.
    • O suporte para uma plataforma mais recente é adicionado.
    • Uma versão mais recente PATCH de uma dependência existente é adotada.
    • Qualquer outra alteração não se encaixa em um dos casos anteriores.

Quando há várias alterações, o elemento mais alto afetado por alterações individuais é incrementado e os seguintes são redefinidos para zero. Por exemplo, quando MAJOR é incrementado, MINOR.PATCH são redefinidos para zero. Quando MINOR é incrementado, PATCH é redefinido para zero enquanto MAJOR permanece o mesmo.

Números de versão em nomes de arquivo

Os arquivos baixados para .NET carregam a versão, por exemplo, dotnet-sdk-5.0.301-win-x64.exe.

Versões de visualização

As versões de visualização têm um -preview.[number].[build] adicionado ao número de versão. Por exemplo, 6.0.0-preview.5.21302.13.

Versões de manutenção

Depois que uma nova versão é lançada, as branches de lançamento geralmente param de produzir compilações diárias e, em vez disso, começam a produzir compilações de manutenção. As versões de manutenção têm uma -servicing-[number] acrescentada à versão. Por exemplo, 5.0.1-servicing-006924.

Compatibilidade do .NET Runtime

O Runtime do .NET mantém um alto nível de compatibilidade entre as versões. Os aplicativos .NET devem, em geral, continuar funcionando após a atualização para uma nova versão principal do Runtime do .NET.

Cada versão principal do .NET Runtime contém alterações significativas intencionais, cuidadosamente verificadas e documentadas. As mudanças disruptivas documentadas não são a única fonte de problemas que podem afetar um aplicativo após a atualização. Por exemplo, uma melhoria de desempenho no .NET Runtime (que não é considerada uma alteração significativa) pode expor bugs latentes de threading de aplicativo que fazem com que o aplicativo não funcione nessa versão. Espera-se que aplicativos grandes exijam algumas correções após a atualização para uma nova versão principal do Runtime do .NET.

Por padrão, os aplicativos .NET são configurados para serem executados em uma determinada versão principal do Runtime do .NET, portanto, a recompilação é altamente recomendada para atualizar o aplicativo para ser executado em uma nova versão principal do Runtime do .NET. Em seguida, verifique novamente o aplicativo após a atualização para identificar quaisquer problemas.

Suponha que a atualização por meio da recompilação de aplicativo não seja viável. Nesse caso, o Runtime do .NET fornece configurações adicionais para permitir que um aplicativo seja executado em uma versão maior do .NET Runtime do que a versão para a qual ele foi compilado. Essas configurações não alteram os riscos envolvidos na atualização do aplicativo para uma versão mais alta do Runtime do .NET e ainda é necessário verificar novamente a pós-atualização do aplicativo.

O Runtime do .NET dá suporte ao carregamento de bibliotecas direcionadas a versões mais antigas do Runtime do .NET. Um aplicativo atualizado para uma versão mais recente do Runtime do .NET pode fazer referência a bibliotecas e pacotes NuGet direcionados a versões mais antigas do Runtime do .NET. É desnecessário atualizar simultaneamente a versão de runtime de destino de todas as bibliotecas e pacotes NuGet referenciados pelo aplicativo.

Consulte também