Magento 2: Modülümün composer.json dosyasında “Anlamsal Sürüm Oluşturma” Bağımlılıkları Nasıl Belirtilir

Magento 2'nin gelişimi ve devreye alınması, çekirdek Magento modüllerinin büyük ve küçük sürümlerinin geriye dönük uyumlu özelliklerde yapılan değişikliklere dayanarak oluşturulacağı resmi bir süreç içerir .

Magento modülü geliştiricisi olarak kendi composer.json dosyamdaki gereksinimlerin bir listesini nasıl oluşturmalıyım? Bir çekirdek Magento kodu parçası her kullandığımda ve require:...composer.json'a bir satır eklediğimde modülüme manuel olarak bakmam gerekir mi? Yoksa bunu benim için yapabilen otomatik bir araç var mı?

İçime eklenecek bir sürümü nasıl belirtebilirim composer.json? Geliştirdiğim özel modül versiyonu olmalı mı? Yoksa bana bir tür joker karakter dahil mi? Yoksa ödünleşmeden yola çıkarak karar vermem gerekiyor mu? Öyleyse, her bir sürüm stili için yapılan ödünleşimler nelerdir?

Bu özelliğin etrafta yüzen birçok üst düzey açıklaması var - ancak çalışan bir geliştiricinin burada ne gibi pratik adımlar atması gerektiği ve / veya bu adımların gerçek sonuçlarının ne olduğu çok açık değil.

Bir çekirdek Magento kodu parçası her kullandığımda ve composer.json'a bir requir: ... satırı eklediğimde modülüme manuel olarak bakmam gerekir mi?

Evet, kodunuzda her zaman bir çekirdek modülden herhangi bir şey kullandığınızda, bunu bestecinizin isteğine eklemeniz gerekir. Muhtemelen yükleme siparişinizin çekirdek modülden sonra olmasını istediğiniz gibi, bunu module.xmlsıralama bölümünde dosyanıza eklemenizi de öneririm .

Yoksa bunu benim için yapabilen otomatik bir araç var mı?

Henüz karşılaşmadım. Varsa lütfen bana bildirin. Oldukça sofistike bir araç olması gerekir ve muhtemelen önemli ölçüde test kapsamı gerektirir ve daha sonra bir çalışma seti üretmek için farklı versiyonlardan oluşan bir matris çalıştırır.

Composer.json'uma eklenecek bir sürümü nasıl belirtebilirim? Geliştirdiğim özel modül versiyonu olmalı mı? Yoksa bana bir tür joker karakter dahil mi? Yoksa ödünleşmeden yola çıkarak karar vermem gerekiyor mu? Öyleyse, her bir sürüm stili için yapılan ödünleşimler nelerdir?

Sürüm numarası tanımlama seçenekleri

1. 100.0.2
   Yalnızca bu belirli sürümde çalışır

2. 100.0.*
*Bir joker ve herhangi bir sürüm numarası ile değiştirilebilir 100.0.0, 100.0.1, ...,100.0.120

3. ~100.0.2
   2 sadece bu kadar gidebilecekleri bir joker yapar 100.0.2, 100.0.3, ...,100.0.120

4. ^100.0.2
   Herhangi 101 kadar serbest verir, böylece 100.0.2, 100.0.3, ..., 100.1.0,100.2.5

Kararlılık ayarlarınız izin veriyorsa 2-4 seçenekleri için aşağıdaki sürümleri de içerecektir 100.0.1-beta

Pratik kullanım

Seçenek 1) en ihtiyatlı olanıdır, hangi sürüme karşı geliştirdiğinizi bilirsiniz ve yalnızca bu belirli sürümle çalışmayı kabul edersiniz - modülünüz yalnızca o sürümdeki belirli modülün yanına kurulabilir. Diğer tüm yükleme / yükseltme girişimleri, yüklenebilir bir bileşen kümesi bulamadığını vurgulayan bir besteci mesajıyla başarısız olur.

Seçenek 2.) Eğer Seçenek 3'ün kapsadığı gibi seçenek olmayan düşünülebilir düşünüyorum) ~100.0.0

Seçenek 3.) Yeni özellik sunulmadığı sürece uyumlu olun

Seçenek 4.) Hiçbir kesme değişikliği yapılmadığı sürece uyumlu olun

Ticari İşlemler

1 Uzantınız bir Magento modülünün yalnızca 1 sürümü için çalışır (teknik olarak bir modülde herhangi bir değişiklik yoksa sürüm numarası artmamalıdır ve birden fazla Magento Project sürümü teorik olarak aynı Magento çekirdek modülünü aynı sürümle içerebilir. bunu görmedim ve Magento ucunda bazı süreç değişiklikleri gerektiriyor gibi görünüyor ). Magento çekirdek modülünün 1 sürümüne çok bağlı olduğunuz için, uyumlu kalmak istiyorsanız, kendi uzantınızın çok sayıda sürümü ve sürümüyle sonuçlanırsınız.

3-4 Uzantınız Magento'nun birden çok sürümüyle çalışır ve Magento her yeni sürüm yayınladığında uzantınızın farklı sürümlerini yayınlamanız gerekmez. Buradaki dezavantaj, Magento'da kendi kodunuzla uyumsuz bir değişiklik yapılsa bile uyumluluk talebinde bulunmanızdır. Magento'nun kendi modül sürümleri için anlamsal sürüm oluşturma tanımı , sınırlı kapsamıyla yalnızca bir @apiek açıklama ile işaretlenmiş olana (bu GitHub sorunu hakkında daha fazla bilgi) uzanır .

tl; dr;
100.0.2Güvenli bir şekilde oynayın, sizin için korumak için çok sayıda
^100.0.2sürüm Semantik Sürüm oluşturma, nasıl çalışması gerektiğini, sizin için daha az sürüm, ancak şu anda @apiaçıklamalı sınıfların ve yöntemlerin sınırlı kapsamı nedeniyle daha yüksek risk altındadır . Yaptırım sınıfları ve yöntemleri kullanarak% 100'lük bir uzantınız olsaydı, bu bariz bir seçim olacaktır.

0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,Modülün kararlılığına dayanabilir . Belgelerde paylaşıldığı gibi gereksinim aşağıdaki gibi olacaktır: -

"require": {
    "myexamplestore/product-bundle": "2.0.0-RC1",
    "myexamplestore/acme-extension": "~1.0"
    }

Güncellemenize dayanarak, bu şu şekilde güncellenmelidir: -

"require": {
    "myexamplestore/product-bundle": "2.4.0-RC1",
    "myexamplestore/acme-extension": "~2.0"
    }

Henüz bunun için otomatik bir sistem olduğunu düşünmüyorum, ancak belgelere göre bunu takip etmek çok önemli.

Ancak modülünüzde küçük hata düzeltmeleri varsa PATCH kullanmalısınız.

Bakın

PATCH, geriye dönük uyumlu hata düzeltmelerini belirtir

Doğru cevap biraz belirsiz, ama yaklaşık 1 yıl geri güncellendi olduğunu görebilirsiniz. Ama işte böyle.