Partilhar via

Como o .NET é versionado

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

O .NET lança uma nova versão principal a cada novembro. Lançamentos de números pares, como o .NET 6 ou o .NET 8, têm suporte a longo prazo (LTS). As versões LTS recebem suporte e patches gratuitos por três anos. As edições ímpares têm suporte de prazo padrão. As versões de suporte de prazo padrão recebem suporte e patches gratuitos por 18 meses.

Detalhes de versionamento

O .NET Runtime tem uma abordagem major.minor.patch para versionamento que segue o versionamento semântico.

O SDK .NET, no entanto, não segue o controle de versão semântico. O SDK do .NET é liberado mais rapidamente e seus números de versão devem comunicar o tempo de execução alinhado e as versões secundárias e de patch do próprio SDK.

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

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

Alteração Tempo de execução do .NET SDK do .NET (*) Observações
Versão inicial 5.0.0 5.0.100 Lançamento inicial.
Patch SDK 5.0.0 5.0.101 O tempo de execução não foi alterado com este patch do SDK. O patch do SDK incrementa o último dígito no seu código.
Patch de tempo de execução e SDK 5.0.1 5.0.102 O patch de tempo de execução aumenta o número do patch de tempo de execução. O patch do SDK incrementa o último dígito no seu código.
Alteração de recurso do SDK 5.0.1 5.0.200 O patch de runtime não foi modificado. Nova funcionalidade do SDK incrementa o primeiro dígito no patch do SDK.
Patch de execução 5.0.2 5.0.200 O patch de tempo de execução aumenta o número do patch de tempo de execução. O SDK não muda.

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 para um determinado SDK e tempo de execução devem corresponder. Todos os exemplos anteriores fazem parte do fluxo de lançamento do .NET 5.0.
  • A versão de patch do ambiente de execução é incrementada somente quando o ambiente de execução é atualizado. O número de patch do SDK não é atualizado durante um patch de tempo de execução.
  • 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 SDK.

NOTAS:

  • Se o SDK tiver 10 atualizações de funcionalidades 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 esta situação ocorra.
  • 99 lançamentos de patches sem um lançamento de funcionalidades não irão ocorrer. Se uma versão se aproximar desse número, ela forçará um lançamento de funcionalidade.

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

Versionamento semântico

O .NET Runtime segue de forma aproximada o Versionamento Semântico (SemVer), adotando o uso de MAJOR.MINOR.PATCH, utilizando as várias partes do número da 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 das versões suportadas e só existem em builds noturnos, builds locais a partir de código fonte, e versões de pré-visualização sem suporte.

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

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

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

    Os principais lançamentos acontecem uma vez por ano, as versões de número par são versões com suporte de longo prazo (LTS). A primeira versão LTS usando esse esquema de controle de versão é o .NET 6. A versão mais recente não-LTS é o .NET 9.

  • MINOR é incrementado quando:

    • A área de cobertura da API pública foi ampliada.
    • Um novo comportamento é adicionado.
    • Uma versão mais recente MINOR de uma dependência existente é adotada.
    • É introduzida uma nova dependência.

  • PATCH é incrementado quando:

    • Correções de bugs são feitas.
    • É adicionado suporte para uma plataforma mais recente.
    • 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 de maior valor afetado por alterações individuais é incrementado, e os seguintes são reiniciados 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 pré-visualização

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

Versões de manutenção

Depois que uma versão é lançada, as ramificações de liberação 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 um -servicing-[number] anexado à versão. Por exemplo, 5.0.1-servicing-006924.

Compatibilidade com o .NET Runtime

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

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

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

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

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

Ver também