Proses perencanaan untuk rilis

Kami sering mendapatkan pertanyaan tentang bagaimana kami memilih fitur khusus untuk masuk ke rilis tertentu. Dokumen ini menguraikan proses yang kami gunakan. Proses ini terus berkembang karena kami menemukan cara yang lebih baik untuk merencanakan, tetapi ide-ide umum tetap sama.

Berbagai jenis rilis

Jenis rilis yang berbeda berisi berbagai jenis perubahan. Ini pada gilirannya berarti bahwa perencanaan rilis berbeda untuk berbagai jenis rilis.

Rilis patch

Rilis patch hanya mengubah bagian "patch" dari versi. Misalnya, EF Core 3.1.1 adalah rilis yang menambal masalah yang ditemukan di EF Core 3.1.0.

Rilis patch dimaksudkan untuk memperbaiki bug pelanggan penting. Ini berarti rilis patch tidak menyertakan fitur baru. Perubahan API tidak diizinkan dalam rilis patch kecuali dalam keadaan khusus.

Bar untuk membuat perubahan dalam rilis patch sangat tinggi. Ini karena sangat penting bahwa rilis patch tidak memperkenalkan bug baru. Oleh karena itu, proses keputusan menekankan nilai tinggi dan risiko rendah.

Kami lebih cenderung menambal masalah jika:

• Hal ini berdampak pada beberapa pelanggan
• Ini adalah regresi dari rilis sebelumnya
• Kegagalan menyebabkan kerusakan data

Kami cenderung tidak menambal masalah jika:

• Ada solusi yang wajar
• Perbaikan memiliki risiko tinggi melanggar sesuatu yang lain
• Bug berada dalam kotak sudut

Bar ini secara bertahap naik melalui masa pakai rilis dukungan jangka panjang (LTS ). Ini karena rilis LTS menekankan stabilitas.

Keputusan akhir tentang apakah masalah patch dibuat oleh .NET Directors di Microsoft atau tidak.

Rilisan utama

Rilis utama mengubah nomor versi "utama" EF. Misalnya, EF Core 3.0.0 adalah rilis utama yang membuat langkah besar maju melalui EF Core 2.2.x.

Rilis utama:

• Dimaksudkan untuk meningkatkan kualitas dan fitur rilis sebelumnya
• Biasanya berisi perbaikan bug dan fitur baru
  • Beberapa fitur baru mungkin menjadi perubahan mendasar pada cara kerja EF Core
• Biasanya menyertakan perubahan yang melanggar yang disengaja
  • Perubahan yang melanggar diperlukan bagian dari EF Core yang berkembang seperti yang kita pelajari
  • Namun, kami berpikir sangat hati-hati tentang membuat perubahan yang melanggar karena potensi dampak pelanggan. Kami mungkin terlalu agresif dengan melanggar perubahan di masa lalu. Ke depannya, kami akan berusaha untuk meminimalkan perubahan yang merusak aplikasi, dan untuk mengurangi perubahan yang merusak penyedia dan ekstensi database.
• Memiliki banyak pratinjau prarilis yang didorong ke NuGet

Merencanakan rilis utama/minor

Pelacakan masalah GitHub

GitHub (https://github.com/dotnet/efcore) adalah sumber kebenaran untuk semua perencanaan EF Core.

Masalah di GitHub memiliki:

• Status
  • Masalah terbuka belum diatasi.
  • Masalah tertutup telah diatasi.
    • Semua masalah yang telah diperbaiki ditandai dengan perbaikan tertutup. Masalah yang ditandai dengan perbaikan tertutup diperbaiki dan digabungkan, tetapi mungkin belum dirilis.
    • Label lain closed- menunjukkan alasan lain untuk menutup masalah. Misalnya, duplikat ditandai dengan duplikat tertutup.
• Jenis
  • Bug mewakili bug.
  • Penyempurnaan mewakili fitur baru atau fungsionalitas yang lebih baik dalam fitur yang ada.
• Tonggak pencapaian
  • Masalah tanpa tonggak pencapaian sedang dipertimbangkan oleh tim. Keputusan tentang apa yang harus dilakukan dengan masalah belum dibuat atau perubahan keputusan sedang dipertimbangkan.
  • Masalah dalam tonggak pencapaian Backlog adalah item yang akan dipertimbangkan oleh tim EF dalam rilis mendatang
    • Masalah dalam backlog dapat ditandai dengan pertimbangan untuk rilis berikutnya yang menunjukkan bahwa item kerja ini tinggi dalam daftar untuk rilis berikutnya.
  • Masalah terbuka dalam tonggak pencapaian versi adalah item yang rencananya akan dikerjakan tim dalam versi tersebut. Misalnya, ini adalah masalah yang kami rencanakan untuk dikerjakan untuk EF Core 5.0.
  • Masalah tertutup dalam tonggak pencapaian versi adalah masalah yang diselesaikan untuk versi tersebut. Perhatikan bahwa versi mungkin belum dirilis. Misalnya, ini adalah masalah yang diselesaikan untuk EF Core 3.0.
• Suara!
  • Pemungutan suara adalah cara terbaik untuk menunjukkan bahwa masalah penting untuk Anda.
  • Untuk memilih, cukup tambahkan "thumbs-up" 👍 ke masalah. Misalnya, ini adalah masalah yang dipilih teratas
  • Silakan juga komentar yang menjelaskan alasan spesifik Anda memerlukan fitur jika Anda merasa ini menambah nilai. Mengomentari "+1" atau serupa tidak menambah nilai.

Proses perencanaan

Proses perencanaan lebih terlibat daripada hanya mengambil fitur paling banyak diminta dari backlog. Ini karena kami mengumpulkan umpan balik dari beberapa pemangku kepentingan dengan berbagai cara. Kami kemudian membentuk rilis berdasarkan:

• Input dari pelanggan
• Masukan dari pemangku kepentingan lain
• Arah strategis
• Sumber daya tersedia
• Jadwal

Beberapa pertanyaan yang kami ajukan adalah:

1. Berapa banyak pengembang yang kami pikir akan menggunakan fitur dan seberapa baik akan membuat aplikasi atau pengalaman mereka? Untuk menjawab pertanyaan ini, kami mengumpulkan umpan balik dari banyak sumber — Komentar dan suara tentang masalah adalah salah satu sumber tersebut. Keterlibatan khusus dengan pelanggan penting adalah hal lain.

2. Apa solusi yang dapat digunakan orang jika kami belum menerapkan fitur ini? Misalnya, banyak pengembang dapat memetakan tabel gabungan untuk mengatasi kurangnya dukungan banyak-ke-banyak asli. Jelas, tidak semua pengembang ingin melakukannya, tetapi banyak yang dapat, dan itu dihitung sebagai faktor dalam keputusan kami.

3. Apakah mengimplementasikan fitur ini mengembangkan arsitektur EF Core sehingga menggerakkan kita lebih dekat untuk menerapkan fitur lain? Kami cenderung mendukung fitur yang bertindak sebagai blok penyusun untuk fitur lain. Misalnya, entitas tas properti dapat membantu kami beralih ke dukungan banyak ke banyak, dan konstruktor entitas mengaktifkan dukungan pemuatan malas kami.

4. Apakah fitur tersebut merupakan titik ekstensibilitas? Kami cenderung mendukung titik ekstensibilitas daripada fitur normal karena memungkinkan pengembang untuk menghubungkan perilaku mereka sendiri dan mengkompensasi fungsionalitas yang hilang.

5. Apa sinergi fitur ketika digunakan dalam kombinasi dengan produk lain? Kami mendukung fitur yang memungkinkan atau secara signifikan meningkatkan pengalaman menggunakan EF Core dengan produk lain, seperti .NET Core, versi terbaru Visual Studio, Microsoft Azure, dan sebagainya.

6. Apa keterampilan orang-orang yang tersedia untuk bekerja pada fitur, dan bagaimana kita dapat memanfaatkan sumber daya ini dengan terbaik? Setiap anggota tim EF dan kontributor komunitas kami memiliki tingkat pengalaman yang berbeda di berbagai bidang, jadi kami harus merencanakannya. Bahkan jika kita ingin memiliki "semua tangan di dek" untuk mengerjakan fitur tertentu seperti terjemahan GroupBy, atau banyak ke banyak, itu tidak akan praktis.