Sürüm planlama süreci
Genellikle belirli bir sürüme gitmek için belirli özellikleri nasıl seçtiğimiz hakkında sorular alacağız. Bu belgede kullandığımız işlem özetlenmiştir. Planlama için daha iyi yollar bulduğumuz için süreç sürekli olarak gelişmektedir, ancak genel fikirler aynı kalır.
Farklı sürüm türleri
Farklı sürüm türleri farklı türde değişiklikler içerir. Bu da sürüm planlamasının farklı sürüm türleri için farklı olduğu anlamına gelir.
Düzeltme eki sürümleri
Düzeltme eki sürümleri, sürümün yalnızca "düzeltme eki" bölümünü değiştirir. Örneğin, EF Core 3.1.1, EF Core 3.1'de bulunan sorunları düzelten bir sürümdür.0.
Düzeltme eki sürümleri, kritik müşteri hatalarını düzeltmeye yöneliktir. Bu, düzeltme eki sürümlerinin yeni özellikler içermediği anlamına gelir. Özel durumlar dışında düzeltme eki yayınlarında API değişikliklerine izin verilmez.
Yama sürümünde değişiklik yapmak için çıta çok yüksektir. Bunun nedeni, düzeltme eki sürümlerinin yeni hatalara neden olmamasının kritik olmasıdır. Bu nedenle, karar süreci yüksek değeri ve düşük riski vurgular.
Aşağıdakiler durumunda bir soruna düzeltme eki uygulama olasılığımız daha yüksektir:
- Birden çok müşteriyi etkiliyor
- Önceki bir sürümden gelen bir regresyondur
- Hata veri bozulmasına neden oluyor
Aşağıdakiler durumunda bir soruna düzeltme eki uygulama olasılığımız daha düşüktür:
- Makul geçici çözümler vardır
- Düzeltmenin başka bir şeyi bozma riski yüksek
- Hata bir köşe durumunda
Bu çubuk, uzun süreli destek (LTS) sürümünün kullanım ömrü boyunca kademeli olarak artar. Bunun nedeni LTS sürümlerinin kararlılığı vurgular.
Bir soruna düzeltme eki uygulama veya düzeltme eki uygulamama konusunda son karar Microsoft'taki .NET Yöneticileri tarafından verilir.
Önemli sürümler
Ana sürümler EF "ana" sürüm numarasını değiştirir. Örneğin EF Core 3.0.0, EF Core 2.2.x üzerinde büyük bir adım atan önemli bir sürümdür.
Önemli sürümler:
- Önceki sürümün kalitesini ve özelliklerini iyileştirmeye yöneliktir
- Genellikle hata düzeltmeleri ve yeni özellikler içerir
- Yeni özelliklerden bazıları EF Core'un çalışma şekliyle ilgili temel değişiklikler olabilir
- Genellikle kasıtlı hataya neden olan değişiklikleri içerir
- Hataya neden olan değişiklikler, öğrendikkçe EF Core'un gelişmesinin gerekli bir parçasıdır
- Ancak, potansiyel müşteri etkisi nedeniyle herhangi bir hataya neden olan değişikliğin yapılması konusunda çok dikkatli düşünüyoruz. Geçmişteki hataya neden olan değişiklikler konusunda çok agresif olabilirdik. Bundan sonra, uygulamaları bozan değişiklikleri en aza indirmek ve veritabanı sağlayıcılarını ve uzantılarını bozan değişiklikleri azaltmak için çabalayacağız.
- NuGet'e gönderilen birçok ön sürüm önizlemesi var
Ana/ikincil sürümleri planlama
GitHub sorun izleme
GitHub (https://github.com/dotnet/efcore), tüm EF Core planlamaları için gerçeklerin kaynağıdır.
GitHub'da karşılaşılan sorunlar:
- Durum
- Açık sorunlar giderilmedi.
- Kapatılan sorunlar giderildi.
- Düzeltilmiş olan tüm sorunlar kapalı düzeltilmiş olarak etiketlenir. Kapalı düzeltildi olarak etiketlenen bir sorun düzeltildi ve birleştirildi, ancak yayımlanmamış olabilir.
- Diğer
closed-
etiketler, bir sorunu kapatmanın diğer nedenlerini gösterir. Örneğin, yinelenenler kapalı yineleme ile etiketlenir.
- Bir tür
- Hatalar hataları temsil ediyor.
- Geliştirmeler yeni özellikleri veya mevcut özelliklerdeki daha iyi işlevleri temsil eder.
- Kilometre taşı
- Kilometre taşı olmayan sorunlar ekip tarafından dikkate alınıyor. Sorunla ilgili ne yapılacağına ilişkin karar henüz verilmemiş veya kararda bir değişiklik düşünülmektedir.
- Kapsam kilometre taşındaki sorunlar, EF ekibinin gelecek bir sürümde üzerinde çalışmayı düşüneceği öğelerdir
- Kapsamtaki sorunlar, bu iş öğesinin bir sonraki sürüm için listede yüksek olduğunu belirten sonraki sürüm için düşünün ile etiketlenebilir.
- Sürüme alınan bir kilometre taşındaki açık sorunlar, ekibin bu sürümde üzerinde çalışmayı planladığı öğelerdir. Örneğin, EF Core 5.0 için üzerinde çalışmayı planladığımız sorunlar bunlardır.
- Sürümlenmiş kilometre taşındaki kapalı sorunlar, bu sürüm için tamamlanan sorunlardır. Sürümün henüz yayımlanmamış olabileceğini unutmayın. Örneğin, EF Core 3.0 için tamamlanan sorunlar bunlardır.
- Oy!
- Oylama, bir sorunun sizin için önemli olduğunu göstermenin en iyi yoludur.
- Oy vermek için soruna bir "başparmak" 👍 eklemeniz gerekir. Örneğin, bunlar en çok oy alan sorunlardır
- Ayrıca, bu özelliğin değer kattığına ilişkin belirli nedenler hakkında da yorumda bulunabilirsiniz. "+1" veya benzeri bir açıklama eklemek değer katmaz.
Planlama süreci
Planlama süreci, yalnızca en çok istenen özellikleri kapsam dışında ele almaktan daha önemlidir. Bunun nedeni, birden çok paydaştan çeşitli yollarla geri bildirim toplamamızdır. Ardından bir sürümü şu şekilde şekillendireceğiz:
- Müşterilerden gelen girişler
- Diğer paydaşlardan gelen girişler
- Stratejik yön
- Kullanılabilir kaynaklar
- Zamanla
Sorduğumuz sorulardan bazıları şunlardır:
Bu özelliği kaç geliştiricinin kullanacağını ve uygulamalarını veya deneyimlerini ne kadar daha iyi hale getireceğini düşünüyoruz? Bu soruyu yanıtlamak için birçok kaynaktan geri bildirim toplarız; sorunlar hakkındaki yorumlar ve oylar bu kaynaklardan biridir. Önemli müşterilerle belirli etkileşimler başka bir görevlendirmedir.
Bu özelliği henüz uygulamazsak, kişilerin kullanabileceği geçici çözümler nelerdir? Örneğin, birçok geliştirici yerel çoka çok desteğinin olmamasını geçici olarak çözmek için bir birleştirme tablosunu eşleyebilir. Açıkçası, tüm geliştiriciler bunu yapmak istemiyor, ancak çoğu bunu yapabilir ve bu kararımızın bir faktörü olarak sayılır.
Bu özelliğin uygulanması EF Core mimarisini, bizi diğer özellikleri uygulamaya yaklaştıracak şekilde mi geliştiriyor? Diğer özellikler için yapı taşları gibi davranan özellikleri tercih etme eğilimindeyiz. Örneğin, özellik paketi varlıkları çoka çok desteğine geçmemize yardımcı olabilir ve varlık oluşturucuları gecikmeli yükleme desteğimizi etkinleştirdi.
Özellik bir genişletilebilirlik noktası mı? Geliştiricilerin kendi davranışlarını bağlamasına ve eksik işlevleri telafi etmelerine olanak sağladığından, genişletilebilirlik noktalarını normal özelliklere tercih etme eğilimindeyiz.
Diğer ürünlerle birlikte kullanıldığında özelliğin sinerjisi nedir? EF Core'u .NET Core, Visual Studio'nun en son sürümü, Microsoft Azure vb. gibi diğer ürünlerle kullanma deneyimini etkinleştiren veya önemli ölçüde geliştiren özellikleri tercih ediyoruz.
Bir özellik üzerinde çalışabilecek kişilerin becerileri nelerdir ve bu kaynaklardan en iyi şekilde nasıl yararlanabiliriz? EF ekibinin her üyesi ve topluluk katkıda bulunanlarımızın farklı alanlarda farklı deneyim düzeyleri vardır, bu nedenle buna göre planlama yapmamız gerekir. GroupBy çevirileri veya çoka çok gibi belirli bir özellik üzerinde çalışmak için "tüm eller güvertede" olsun isteseydik bile bu pratik olmazdı.