Processus de planning des versions

  • Article

On nous demande souvent comment nous choisissons les fonctionnalités qui seront intégrées dans une version donnée. Ce document décrit le processus que nous utilisons. Le processus évolue continuellement à mesure que nous trouvons de meilleures façons de mettre en œuvre nos planifications, mais les idées générales restent les mêmes.

Différents types de versions

Différents types de versions contiennent différents types de modifications. Cela signifie à son tour que la planification de la version est différente pour différents types de versions.

Versions correctives

Les versions correctives modifient uniquement la partie « patch » de la version. Par exemple, EF Core 3.1.1 est une version qui corrige les problèmes détectés dans EF Core 3.1.0.

Les versions correctives sont destinées à corriger les bogues critiques des clients. Cela signifie que les versions correctives n’incluent pas de nouvelles fonctionnalités. Les modifications d’API ne sont pas autorisées dans les versions correctives, sauf dans des circonstances particulières.

La barre à modifier dans une version corrective est très élevée. Cela est dû au fait qu’il est essentiel que les versions correctives n’introduisent pas de nouveaux bogues. Par conséquent, le processus de décision met l’accent sur la valeur élevée et le faible risque.

Nous sommes plus susceptibles de corriger un problème si :

  • Il a un impact sur plusieurs clients
  • Il s’agit d’une régression d’une version précédente
  • L’échec provoque une altération des données

Nous sommes moins susceptibles de corriger un problème si :

  • Il existe des solutions raisonnables pour contourner le problème
  • Le correctif présente un risque élevé de rupture d’un autre élément
  • Le bogue se trouve dans un cas pathologique

Cette barre augmente progressivement pendant la durée de vie d’une version de support à long terme (LTS). Cela est dû au fait que les versions LTS mettent l’accent sur la stabilité.

La décision finale quant à la résolution ou non d’un problème est prise par les directeurs .NET chez Microsoft.

Versions majeures

Les versions majeures modifient le numéro de version EF « major ». Par exemple, EF Core 3.0.0 est une version majeure qui fait un grand pas en avant par rapport à EF Core 2.2.x.

Versions majeures :

  • Elles sont destinées à améliorer la qualité et les fonctionnalités de la version précédente
  • Elles contiennent généralement des correctifs de bogues et de nouvelles fonctionnalités
    • Certaines des nouvelles fonctionnalités peuvent être des changements fondamentaux de la façon dont EF Core fonctionne
  • En règle générale, elle inclut des changements cassants intentionnels
    • Les changements cassants sont une partie intégrante de l’évolution d’EF Core à mesure que nous apprenons
    • Toutefois, nous réfléchissons très attentivement avant de faire toute modification cassant en raison de l’impact potentiel du client. Nous avons peut-être été trop agressifs avec des changements cassants dans le passé. À l’avenir, nous nous efforcerons de minimiser les modifications qui interrompent les applications et de réduire les modifications qui interrompent les fournisseurs de base de données et les extensions.
  • Avoir de nombreuses pré-publications des préversions envoyées à NuGet

Planification des versions majeures/mineures

Suivi des problèmes GitHub

GitHub (https://github.com/dotnet/efcore) est la source de référence pour toutes les planifications EF Core.

Problèmes sur GitHub :

  • État
    • Les problèmes ouverts n’ont pas été résolus.
    • Les problèmes fermés ont été résolus.
      • Tous les problèmes qui ont été résolus sont étiquetés avec « close-fixed » (fermé : corrigé) . Un problème étiqueté avec la correction fermée est résolu et fusionné, mais n’a peut-être pas été publié.
      • D’autres étiquettes closed- indiquent d’autres raisons de fermer un problème. Par exemple, les doublons sont étiquetés avec des doublons fermés.
  • Type
    • Les bogues représentent des bogues.
    • Les améliorations représentent de nouvelles fonctionnalités ou une meilleure utilisation des fonctionnalités existantes.
  • Un jalon
  • Votes !
    • Le vote est la meilleure façon d’indiquer qu’un problème est important pour vous.
    • Pour voter, il suffit d’ajouter un « pouce levé » 👍 au problème. Par exemple, voici les problèmes les plus votés
    • Veuillez également commenter la description des raisons spécifiques dont vous avez besoin si vous sentez que cela peut ajouter des éléments importants. Le commentaire « +1 » ou similaire n’ajoute pas d’éléments importants.

Le processus de planification

Le processus de planification est plus complexe que le simple fait de prendre les fonctionnalités les plus demandées du backlog. Cela est dû au fait que nous collectons des commentaires de plusieurs parties prenantes de plusieurs façons différentes. Nous modélisons ensuite une version basée sur :

  • Les commentaires des clients
  • Les commentaires d’autres parties prenantes
  • L’orientation stratégique
  • Les ressources disponibles
  • Planification

Voici quelques-unes des questions que nous posons :

  1. Combien de développeurs vont utiliser la fonctionnalité selon nous et dans quelle mesure va-t-elle améliorer leurs applications ou leur expérience ? Pour répondre à cette question, nous recueillons les commentaires provenant de nombreuses sources (les commentaires et votes sur les problèmes en sont une). Des engagements spécifiques avec des clients importants sont une autre source.

  2. Quelles sont les solutions de contournement possibles si nous n’implémentons pas encore cette fonctionnalité ? Par exemple, de nombreux développeurs peuvent mapper une table de jointure afin de pallier l’absence de prise en charge native du mappage plusieurs-à-plusieurs. Évidemment, tous les développeurs ne peuvent pas le faire, mais beaucoup en sont capables, ce qui constitue un facteur important dans notre décision.

  3. L’implémentation de cette fonctionnalité fait-elle évoluer l’architecture d’EF Core de telle manière que l’implémentation d’autres fonctionnalités s’en voit facilitée ou plus probable ? Nous avons tendance à privilégier les fonctionnalités qui agissent comme blocs de construction pour d’autres fonctionnalités. Par exemple, les entités de sac de propriétés peuvent faciliter le passage à la prise en charge du mappage plusieurs-à-plusieurs et les constructeurs d’entité permettent la prise en charge de notre chargement différé.

  4. La fonctionnalité est-elle un point d’extensibilité ? Nous avons tendance aussi à favoriser les points d’extensibilité au détriment des fonctionnalités standard, car ils permettent aux développeurs de raccorder leurs propres comportements et d’obtenir ainsi une compensation pour certaines fonctionnalités manquantes.

  5. Quelle est la synergie de la fonctionnalité quand elle est utilisée conjointement avec d’autres produits ? Nous favorisons les fonctionnalités qui permettent ou améliorent considérablement l’utilisation d’EF Core avec d’autres produits, comme .NET Core, la dernière version de Visual Studio, Microsoft Azure et ainsi de suite.

  6. Quelles sont les compétences des personnes disponibles pour travailler sur une fonctionnalité et comment tirer le meilleur parti de ces ressources ? Chaque membre de l’équipe EF et nos collaborateurs de la Communauté ont différents niveaux d’expérience dans différents domaines, et nous devons donc planifier en conséquence. Même si nous souhaitions faire appel en même temps à toutes ces ressources pour travailler sur une fonctionnalité spécifique telle que les traductions GroupBy ou le mappage plusieurs-à-plusieurs, ce ne serait pas pratique.