Yeni değişiklikler

MRTK 'ın tüketicileri, kararlı bir yayın API 'SI yüzeyine bağlıdır, böylece her seferinde büyük bir değişiklik yapmadan MRTK üzerinde güncelleştirme gerçekleştirebilir.

Bu sayfada, önemli değişiklikleri düşük tutarak ve kodda doğru uzun süreli teknik değişiklikleri yapabildiğimiz için, MRTK 'daki önemli değişikliklere ilişkin geçerli ilkeniz açıklanmaktadır.

Son değişiklik nedir?

Değişiklik, listedeki koşulların herhangi birini karşılıyorsa ve B listesindeki tüm koşulları karşılıyorsa, bir değişiklik bir son değişiklik değildir

Liste A

  • Herhangi bir arabirimin üye veya işlevinin eklenmesi, kaldırılması veya güncelleştirilmesi (ya da tüm arabirimin kaldırılması/yeniden adlandırılması).
  • Herhangi bir korumalı veya ortak üye ya da sınıf işlevinin kaldırılması, güncelleştirilmesi (tür/tanım değiştirme, özel veya iç hale getirme). (veya tüm sınıfın kaldırılması/yeniden adlandırılması).
  • Bir sınıf tarafından tetiklenen olaylar sırasındaki değişiklik.
  • Herhangi bir özel SerializedField (karşılık gelen bir FormerlySerializedAs etiketi olmadan) veya bir ScriptableObject üzerinde public özelliği (özellikle profillerdeki değişiklikler) yeniden adlandırma.
  • ScriptableObject üzerindeki bir alanın türünü değiştirme (özellikle profillerdeki değişiklikler).
  • Ad alanı veya herhangi bir sınıfın veya arabirimin asmdefs ' i için güncelleştirmeler.
  • Prefab 'nin en üst düzey nesnesinde herhangi bir prefab veya bir betiğin kaldırılması kaldırılıyor.

Liste B

  • Söz konusu varlık, Foundation paketinde (yani, aşağıdaki klasörlerden birinde bulunur):

    • MRTK/çekirdek
    • MRTK/sağlayıcılar/
    • MRTK/hizmetler/
    • MRTK/SDK/
    • MRTK/uzantılar
  • Söz konusu varlık deneysel ad alanına ait değil.

Önemli

Örnekler paketinde yer alan herhangi bir varlık (MRTK/örnek/klasör), müşteriler tarafından ' başvuru uygulamaları ' olarak kopyalanıp görüntülenmek üzere tasarlanan ancak çekirdek API ve varlık kümesinin bir parçası olmayan varlıklar tarafından herhangi bir zamanda değiştirilebilir. Deneysel ad alanındaki varlıklar (ya da daha fazla genel olarak, deneysel olarak etiketlenmiş Özellikler), tüm süre boyunca (testler, UX yineleme, belgeler), daha önce geri bildirimde bulunmak için yayımlanmadıklardır. Ancak, testleri ve belgeleri olmadığından ve tüm etkileşimler ve tasarımlar için büyük olasılıkla hiç bir şey olmadığı için, bunları herkese açık bir durumda yayımladık (ör. değiştirme, tamamen kaldırma vb.).

Daha fazla bilgi için bkz. deneysel Özellikler .

Büyük değişiklikler için yüzey alanı çok büyükse, "hiçbir önemli değişiklik yok" ifadesinin olanaksız olduğunu belirten bir mutlak kurala sahip olmak önemlidir. yalnızca önemli bir değişiklik yaparak sane bir şekilde düzeltilemeyecek sorunlar olabilir. Başka bir yöntem koymak için, gerçekten "hiçbir değişiklik yok" gibi bir değişiklik yapmanız mümkün değildir.

Söz konusu ilke, mümkünse büyük değişiklikler yapmaktan kaçınmaktır ve yalnızca değişiklik önemli müşteri veya çerçeve uzun dönem değeri tahakkuk ettirdiğinde bunu yapar.

Son değişiklikler hakkında ne yapmalı

Önemli olmayan bir değişiklik yapmadan ve özelliğin uzun vadeli yapısını ve cansız olması gerekmeden bir şeyi gerçekleştirmek mümkün değilse, bu değişikliği ortadan kaldırmayın. Başka bir yol yoksa, değişikliği alan avantajın, değişikliği ortaya çıkarmadan bu değişikliği ortadan kaldırma avantajının azaldığını anlamak için, geçerli ilke her bir bireysel değişikliği değerlendirmektir. Ne yapılması gerektiğini ve genellikle çekme isteği veya sorun tartışmasında ne olacağı hakkında daha fazla şey gerçekleşmeyecektir.

Burada çeşitli demetlere yer verilmiştir:

Son değişiklik değer ekliyor, ancak kırılmaya yönelik olmayan bir şekilde yazılabilir

Örneğin, Bu PR , başlangıçta kırılmış bir şekilde yazılmış yeni bir özellik ekledi. var olan bir arabirimi değiştirdi, ancak daha sonra özelliğin kendi arabirimi olarak bölündüğü yere yazıldı. Bu genellikle olası en iyi sonucu verir. Bir değişikliği, uzun süreli olmayan bir biçime zorlamaya çalışmayın, bu durum, özelliğin büyük vadeli işlem yeteneğini veya yapısını tehlikeye atabilir.

Son değişiklik, müşteriye gereken değere uygun bir değer ekler

Son değişikliklerin ne olduğunu belgeleyin ve mümkün olan en iyi hafifletme şeklini (örneğin, geçiş yapmak için gereken adım adımları veya müşteriye otomatik olarak geçirilecek daha iyi bir araç) sağlar. Her sürümde önemli miktarda değişiklik olabilir. Bu, Buçekme isteği için her zaman belgeler ' de belirtildiği gibi belgelenmelidir. Zaten 2. x. x → 2. x +1. x + 1 Geçiş Kılavuzu varsa, bu belgeye yönerge veya araç ekleyin. Mevcut değilse, oluşturun.

Son değişiklik değer ekliyor, ancak müşteri sorunları çok yüksek

Tüm Son değişiklik türleri eşit değildir; bazıları deneyimimize ve müşteri deneyimlerine göre önemli ölçüde daha neşeli bir şekilde yapılır. Örneğin, arabirimlerde yapılan değişiklikler belki de olabilir, ancak son değişiklik bir müşterinin geçmişte genişletilmiş/uygulanmış olması olası bir süredir (örneğin, tanılama görselleştirme sistemi), gerçek maliyet büyük olasılıkla Nothing olarak düşüktür. Ancak, bu değişiklik ScriptableObject üzerindeki bir alanın türü ise (örneğin, MRTK 'nin çekirdek profillerden birinde), bu büyük olasılıkla müşteri sorunlarına neden olabilir. Müşteriler varsayılan profili zaten klonlanmış, birleştirme/güncelleştirme profillerinin el ile yapması çok zor olabilir (yani, birleştirme sırasında bir metin Düzenleyicisi aracılığıyla) ve varsayılan profilin yeniden yapılandırılması ve her şeyi el ile yeniden yapılandırmak, gerilemelerin hata ayıklamasına yol açacağından son derece olasıdır.

Bu değişiklikler, önemli ölçüde ortadan kalana kadar değişikliklere geri koymaları gerekir (müşterilere yükseltme nedeni sunacak önemli bir değer ile birlikte). Böyle bir dal Şu anda mevcut değil. Gelecekteki yineleme planlama toplantılarımızda, her seferinde bir değişiklik kümesini bir kez daha mantıklı hale getirmek için kritik bir kütle olup olmadığını görmek için ' fazla bölme ' olan değişiklikler/sorunlar kümesini gözden geçitireceğiz. Sahip olduğumuz sınırlı mühendislik kaynakları nedeniyle bir "her şeye izin verildi" dalı ve bu ikisi arasında test ve doğrulama yapmak zorunda olduğumuz olguyu bir şekilde çalıştırmak için tehlikeli olduğunu unutmayın. Bu tür bir dalın bulunduğu durumlarda açık bir amaç ve iyi iletime başlangıç ve bitiş tarihi olması gerekir.

Son değişikliklerin uzun süreli yönetimi

Uzun vadede, B listesindekikoşullar kümesini artırarak, bir son değişiklik olduğunu azaltmak için arama yapılmalıdır. Liste A 'Nın bir dizi kümesini ileri sarma, "ortak API yüzeyi" içinde olması gereken dosya ve varlıklar kümesi için her zaman teknik olarak kesiliyor. Yineleme için biraz daha fazla serbestlik sunduğumuzdan (örn. iç uygulama ayrıntılarını değiştirme, birden fazla sınıf arasında kodun daha kolay yeniden düzenlenmesi ve paylaşılması için izin verilmesi), kodun hangi bölümlerinin uygulama ayrıntısı yerine resmi bir yüzey olduğu konusunda daha açık olması gerekir.

Zaten yaptığımız bir şey, "deneysel" bir özellik kavramını tanıtmaktadır (deneysel ad alanına aittir, testleri/belgeleri olmayabilir ve var olan ancak uyarı olmadan kaldırılabilir ve güncelleştirilmiş olabilir). Bu, daha önce geri bildirimde bulunmak için yeni özellikler ekleme özgürlüğü verdi, ancak API yüzeyine hemen ayrılmadığı için (API yüzeyini tam olarak düşünmeyebilir).

Gelecekte yardımcı olabilecek diğer şeyler örnekleri

  • İç anahtar sözcüğününkullanımı. Bu, dış tüketicilerle ortak hale getirmeden kendi derlemelerimiz dahilinde (kod yinelemeyi azaltmak için) paylaşılan kod sunmamızı sağlar.
  • Bir "iç" ad alanı (örneğin, Microsoft. MixedReality. Toolkit. Internal. Utilities) oluşturma, bu iç ad alanı içinde yer alan herhangi bir şeyin her zaman değişikliğe tabi olduğunu ve kaldırılabileceği, vs. Bu, C++ başlık kitaplıklarının uygulama ayrıntılarını gizlemek için:: internal ad alanlarını nasıl kullananlara benzer.