Processo de planejamento da versão

Frequentemente, recebemos perguntas sobre como escolhemos os recursos específicos de uma versão. Este documento descreve o processo que usamos. O processo evolui continuamente à medida que encontramos melhores maneiras de planejar, mas as ideias gerais permanecem as mesmas.

Diferentes tipos de versões

Diferentes tipos de versão contêm diferentes tipos de alterações. Isso significa que o planejamento de versão é diferente para diferentes tipos de versão.

Versões de patch

As versões de patch alteram apenas a parte da versão onde será feita a correção. Por exemplo, o EF Core 3.1.1 é uma versão que corrige problemas encontrados no EF Core 3.1.0.

As versões de patch destinam-se a corrigir bugs críticos do cliente. Isso significa que elas não incluem novos recursos. As alterações de API não são permitidas nas versões de patch, exceto em casos especiais.

A rigorosidade para fazer uma alteração em uma versão de patch é bastante alta. Isso ocorre porque é fundamental que as versões de patch não introduzam novos bugs. Portanto, o processo de decisão enfatiza o alto valor e o baixo risco.

É mais provável que corrijamos um problema se:

• Estiver afetando vários clientes
• For uma regressão de uma versão anterior
• A falha causar corrupção de dados

É menos provável que corrijamos um problema se:

• Existir soluções alternativas razoáveis
• A correção tiver alto risco de causar falhas em outra coisa
• O bug ocorrer em um caso isolado

Essa rigorosidade se torna gradualmente maior ao longo do tempo de vida de uma versão LTS (suporte de longo prazo). Isso ocorre porque as versões LTS priorizam a estabilidade.

A decisão final sobre a aplicação ou não de patch a um problema é tomada pelos diretores do .NET na Microsoft.

Versões principais

As versões principais alteram o número de versão "principal" do EF. Por exemplo, o EF Core 3.0.0 é uma versão principal que representa um grande avanço em relação ao EF Core 2.2.x.

Versões principais:

• Destinam-se a melhorar a qualidade e os recursos da versão anterior
• Normalmente, contêm correções de bug e novos recursos
  • Alguns dos novos recursos podem ser alterações fundamentais na forma como o EF Core funciona
• Normalmente, inclui alterações interruptivas intencionais
  • As alterações interruptivas são uma parte necessária do processo de evolução do EF Core à medida que aprendemos
  • No entanto, pensamos com muito cuidado antes de fazer qualquer alteração interruptiva devido ao potencial impacto para os clientes. Podemos ter sido muito agressivos com alterações interruptivas no passado. Daqui para frente, nos esforçaremos para minimizar as alterações que interrompem aplicativos e reduzir as alterações que interrompem os provedores de banco de dados e as extensões.
• Possuem muitas versões preliminares enviadas para o NuGet

Planejamento de versões principais/secundárias

Acompanhamento de problemas no GitHub

O GitHub (https://github.com/dotnet/efcore) é a fonte principal de todo o planejamento do EF Core.

Os problemas no GitHub têm:

• Um estado
  • Problemas abertos não foram resolvidos.
  • Problemas fechados foram resolvidos.
    • Todos os problemas corrigidos são marcados com closed-fixed. Um problema marcado com “closed-fixed” é corrigido e mesclado, mas pode não ter sido liberado.
    • Outros rótulos closed- indicam outros motivos para fechar um problema. Por exemplo, duplicados são marcados com closed-duplicate.
• Um tipo
  • Bugs representam bugs.
  • Aprimoramentos representam novos recursos ou funcionalidades melhores em recursos existentes.
• Um marco
  • Problemas sem marco estão sendo considerados pela equipe. Ainda não foi tomada uma decisão sobre o que fazer com o problema ou está sendo considerada uma mudança na decisão.
  • Problemas no marco Lista de pendências são itens em que a equipe do EF considerará trabalhar em versões futuras
    • Os problemas na lista de pendências podem ser marcados com consider-for-next-release indicando que este item de trabalho está no topo da lista para a próxima versão.
  • Problemas abertos em um marco com versão são itens em que a equipe planeja trabalhar nessa versão. Por exemplo, esses são os problemas em que planejamos trabalhar para o EF Core 5.0.
  • Problemas fechados em um marco com versão são problemas que estão concluídos para aquela versão. Observe que a versão ainda pode não ter sido lançada. Por exemplo, esses são os problemas concluídos para o EF Core 3.0.
• Votos!
  • A votação é a melhor maneira de indicar que um problema é importante para você.
  • Para votar, basta clicar em "curtir" 👍 na questão. Por exemplo, essas são as questões mais votadas
  • Comente também descrevendo razões específicas pelas quais você precisa deste recurso, se você acredita que isso irá acrescentar valor. Comentar "+1" ou algo parecido não agrega valor.

O processo de planejamento

O processo de planejamento é mais abrangente do que apenas selecionar as funcionalidades mais solicitadas da lista de pendências. Isso ocorre porque coletamos comentários de diversos stakeholders de várias maneiras. Em seguida, moldamos uma versão com base:

• Nas contribuições dos clientes
• Nas contribuições de outros stakeholders
• Em direção estratégica
• Nos recursos disponíveis
• Agendar

Algumas das perguntas que fazemos são:

1. Quantos desenvolvedores achamos que usarão o recurso? Como ele vai aprimorar os aplicativos ou as experiência deles? Para responder a essa pergunta, podemos coletar comentários de várias fontes – comentários e votos em problemas é uma dessas fontes. Compromissos específicos com clientes importantes é outro.

2. Quais são as soluções alternativas que podem ser usadas caso não implementemos este recurso? Por exemplo, diversos desenvolvedores podem mapear uma tabela de junção para solucionar a falta de suporte nativo de muitos para muitos. Obviamente, nem todos os desenvolvedores desejam fazê-lo, mas muitos podem, e isso conta como um fator em nossa decisão.

3. Implementar este recurso desenvolve a arquitetura do EF Core de forma que nos aproxime da implementação de outros recursos? Favorecemos os recursos que atuam como blocos de construção para outros recursos. Por exemplo, entidades de recipiente da propriedades podem nos ajudar a mover na direção do suporte de muitos-para-muitos, e construtores de entidade habilitaram o nosso suporte a carregamento lento.

4. O recurso é um ponto de extensibilidade? Favorecemos os pontos de extensibilidade em relação aos recursos normais, pois eles permitem aos desenvolvedores conectar seus próprios comportamentos e compensar qualquer funcionalidade ausente.

5. O que é a sinergia do recurso quando usado em combinação com outros produtos? Favorecemos recursos que habilitam ou melhoram significativamente a experiência de usar o EF Core com outros produtos, como .NET Core, a versão mais recente do Visual Studio, Microsoft Azure e assim por diante.

6. Quais são as habilidades das pessoas disponíveis para trabalhar em um recurso e como podemos aproveitar melhor esses recursos? Cada membro da equipe do EF e os colaboradores da comunidade têm diferentes níveis de experiência em áreas distintas, portanto, temos que planejar adequadamente. Mesmo se quiséssemos que todos se empenhassem em trabalhar em um recurso específico, como as traduções do GroupBy ou muitos para muitos, isso não seria prático.