Processo di pianificazione delle versioni

Viene chiesto spesso in che modo vengano scelte le funzionalità da inserire in una versione specifica. Questo documento descrive il processo usato. Il processo è in continua evoluzione, poiché troviamo modi migliori per pianificare, ma le idee generali rimangono invariate.

Tipi diversi di versioni

Diversi tipi di rilascio contengono diversi tipi di modifiche. Ciò a sua volta significa che la pianificazione del rilascio è diversa per diversi tipi di rilascio.

Versioni patch

Le versioni patch modificano solo la parte "patch" della versione. Ad esempio, EF Core 3.1.1 è una versione che applica patch ai problemi rilevati in EF Core 3.1.0.

Le versioni patch sono destinate a correggere i bug critici dei clienti. Ciò significa che le versioni patch non includono nuove funzionalità. Le modifiche all'API non sono consentite nelle versioni patch tranne in circostanze speciali.

La barra per apportare una modifica in una versione patch è molto elevata. Ciò è dovuto al fatto che è fondamentale che le versioni di patch non introducono nuovi bug. Pertanto, il processo decisionale sottolinea valore elevato e basso rischio.

È più probabile che si verifichi un problema se:

• Influisce su più clienti
• Si tratta di una regressione rispetto a una versione precedente
• L'errore causa il danneggiamento dei dati

È meno probabile che si verifichi un problema se:

• Esistono soluzioni alternative ragionevoli
• La correzione ha un rischio elevato di interruzione di qualcos'altro
• Il bug si trova in un caso d'angolo

Questa barra aumenta gradualmente fino alla durata di una versione LTS (Long-Term Support). Ciò è dovuto al fatto che le versioni LTS enfatizzano la stabilità.

La decisione finale su se applicare o meno una patch a un problema viene presa dai director .NET di Microsoft.

Versioni principali

Le versioni principali modificano il numero di versione "principale" di Entity Framework. Ad esempio, EF Core 3.0.0 è una versione principale che fa un grande passo avanti rispetto a EF Core 2.2.x.

Versioni principali:

• Sono progettati per migliorare la qualità e le funzionalità della versione precedente
• In genere contengono correzioni di bug e nuove funzionalità
  • Alcune delle nuove funzionalità possono essere modifiche fondamentali al funzionamento di EF Core
• In genere includere modifiche intenzionali che causano un'interruzione
  • Le modifiche che causano un'interruzione sono necessarie per l'evoluzione di EF Core man mano che si apprendono
  • Tuttavia, riteniamo molto attentamente di apportare qualsiasi modifica di rilievo a causa del potenziale impatto del cliente. Potremmo essere troppo aggressivi con cambiamenti di rilievo in passato. In futuro, ci sforziamo di ridurre al minimo le modifiche che interrompono le applicazioni e ridurre le modifiche che interrompono i provider di database e le estensioni.
• È stato eseguito il push di molte anteprime non definitive in NuGet

Pianificazione delle versioni principali/secondarie

Rilevamento dei problemi di GitHub

GitHub (https://github.com/dotnet/efcore) è l'origine della verità per tutta la pianificazione di EF Core.

I problemi in GitHub hanno:

• Uno stato
  • I problemi aperti non sono stati risolti.
  • Sono stati risolti i problemi chiusi .
    • Tutti i problemi risolti vengono contrassegnati con closed-fixed. Un problema contrassegnato con closed-fixed è stato risolto e unito, ma potrebbe non essere stato rilasciato.
    • Altre closed- etichette indicano altri motivi per la chiusura di un problema. Ad esempio, i duplicati vengono contrassegnati con duplicati chiusi.
• Tipo
  • I bug rappresentano bug.
  • I miglioramenti rappresentano nuove funzionalità o funzionalità migliori nelle funzionalità esistenti.
• Un'attività cardine
  • I problemi senza attività cardine vengono considerati dal team. La decisione su cosa fare con il problema non è ancora stata presa in considerazione o una modifica nella decisione.
  • I problemi nell'attività cardine Backlog sono elementi che il team di Entity Framework considererà di lavorare in una versione futura
    • I problemi nel backlog possono essere contrassegnati con consider-for-next-release che indicano che questo elemento di lavoro è elevato nell'elenco per la versione successiva.
  • I problemi aperti in un'attività cardine con controllo delle versioni sono elementi che il team prevede di lavorare in tale versione. Ad esempio, questi sono i problemi su cui si prevede di lavorare per EF Core 5.0.
  • I problemi chiusi in un'attività cardine con controllo delle versioni sono problemi completati per tale versione. Si noti che la versione potrebbe non essere ancora stata rilasciata. Ad esempio, questi sono i problemi completati per EF Core 3.0.
• Voti!
  • Il voto è il modo migliore per indicare che un problema è importante per voi.
  • Per votare, basta aggiungere un "thumbs-up" 👍 al problema. Ad esempio, si tratta dei problemi più votati
  • Si prega anche di commentare la descrizione di motivi specifici per cui è necessaria la funzionalità se si ritiene che questo valore venga aggiunto. Il commento di "+1" o simile non aggiunge valore.

Processo di pianificazione

Il processo di pianificazione è più complesso rispetto all'acquisizione delle funzionalità più richieste dal backlog. Ciò è dovuto al fatto che vengono raccolti feedback da più stakeholder in diversi modi. Si forma quindi una versione basata su:

• Input dei clienti
• Input di altri stakeholder
• Direzione strategica
• Risorse disponibili
• Pianificazione

Alcune delle domande poste sono:

1. Quanti sviluppatori si pensa che useranno la funzionalità e quanto questa migliorerà le loro applicazioni o la loro esperienza? Per rispondere a questa domanda vengono raccolti commenti e suggerimenti provenienti da numerose fonti, una delle quali sono i commenti e i voti per i problemi. Impegni specifici con clienti importanti è un altro.

2. Quali sono le soluzioni alternative utilizzabili finché questa funzionalità non viene implementata? Molti sviluppatori, ad esempio, possono eseguire il mapping di una tabella di join per ovviare alla mancanza del supporto molti-a-molti nativo. Ovviamente, non tutti gli sviluppatori vogliono farlo, ma molti possono e ciò è un fattore di cui tenere conto per la decisione.

3. L'implementazione di questa funzionalità consente un'evoluzione dell'architettura di EF Core tale da facilitare l'implementazione di altre funzionalità? Vengono tendenzialmente favorite le funzionalità che rappresentano la base per altre funzionalità. Ad esempio, le entità contenitore di proprietà possono essere utili per procedere verso l'implementazione del supporto molti-a-molti e i costruttori di entità hanno reso possibile il supporto del caricamento lazy.

4. La funzionalità rappresenta un punto di estensibilità? Vengono tendenzialmente favoriti i punti di estendibilità rispetto alle normali funzionalità, perché consentono agli sviluppatori di collegare i propri comportamenti e di compensare eventuali funzionalità mancanti.

5. Qual è la sinergia della funzionalità quando viene usata in combinazione con altri prodotti? Vengono favorite le funzionalità che consentono l'uso o che migliorano significativamente l'esperienza d'uso di EF Core con altri prodotti, ad esempio .NET Core, la versione più recente di Visual Studio, Microsoft Azure e così via.

6. Quali sono le competenze delle persone disponibili per lavorare su una funzionalità e come possiamo sfruttare al meglio queste risorse? Ogni membro del team EF e i collaboratori della community hanno diversi livelli di esperienza in aree diverse ed è quindi necessario pianificare di conseguenza. Anche se si volesse usufruire della collaborazione di tutti su una funzionalità specifica, ad esempio le traslazioni GroupBy o il supporto molti-a-molti, questo non sarebbe pratico.