Anlamsal Sürüm Oluşturma sürüm numaralarında 4 bileşene izin veriyor mu?

Gördüğüm tüm semantik sürüm örnekleri kullanımda 3 bileşen göstermektedir. En fazla 2 nokta karakteri. Tarihinde $DAYJOB, sürüm numaralarımızda 4 bileşen kullanıyoruz:

5.0.1.2

Anlamsal Sürüm Oluşturma buna izin veriyor mu?

Ve daha üst düzey ve daha tartışmalı bir yan soru olarak, bu gerçekten önemli mi? Anlamsal sürüm oluşturmayı zorlamanın iyi bir fikir olabileceğini düşünmeye başladım, ancak sonuçta PCI gibi varlıklar onu geçersiz kılıyor.

PCI yorumumda açıklığa kavuşmalıydım. Mesele, büyük ve küçük bileşenler değiştiğinde, denetimlerin ve maliyetlerinin, yeni bir özellik olması gerekmediğidir. Örneğin, ödemelerle ilgili bir özellik sunulursa, PCI için küçük sayıyı çarparız. Ancak, GUI'deki bir şeyle ilgili yepyeni bir özellik eklersek, eklemez. Sadece yama değişir. Dolayısıyla bu durumda, geliştiriciler olarak bu konuda gerçekten söz sahibi değiliz çünkü bir başkası bu kararları alıyor.

İşlem yükünü / denetimlerini önlemek için normal kuralları atladığınız anlaşılıyor. Bu ... beni ilgilendiriyor.

Yaptığınız şey, artık iç denetim ölçütlerinizi tetiklememek için özellik / alt sürüm numaralarınızı bir yere geri taşımak için ekstra bir sürüm numarasını (küçük PCI rakamınız) bir şekilde kasıtlı olarak yapmaktır.

Her neyse, anlamsal sürüm oluşturma ile ilgili sorunuza ulaşmak için, Anlamsal Sürümlendirme spesifikasyonu şunları belirtiyor:

MAJOR.MINOR.PATCH sürüm numarası verildiğinde:

• Uyumsuz API değişiklikleri yaptığınızda önemli sürüm,
• İşlevleri geriye dönük uyumlu bir şekilde eklediğinizde MINOR sürümü ve
• Geriye dönük uyumlu hata düzeltmeleri yaptığınızda PATCH sürümü.
• Sürüm öncesi ve derleme meta verileri için ek etiketler MAJOR.MINOR.PATCH biçiminin uzantıları olarak mevcuttur .

Vurgu madeni.

Soru şu: ön sürüm / derleme meta verileri için dördüncü karakteri mi kullanıyorsunuz? Ya da temelde bıraktığınız başka bir sürüm göstergesi mi?

Eğer "evet" ise, anlamsal sürüm oluşturma özelliği buna izin verir. "Hayır" ise teknik olarak anlamsal sürümleri takip etmiyorsunuzdur.

Ve daha üst düzey ve daha tartışmalı bir yan soru olarak, bu gerçekten önemli mi?

Katı bir şekilde takip etmek isteyip istemediğiniz, sizin ve ekibinizin vermesi gereken bir karardır. Anlamsal sürüm oluşturmanın amacı API uyumluluğuna yardımcı olmaktır:

API sürümünü etkilemeyen hata düzeltmeleri yama sürümünü, geriye dönük olarak uyumlu API eklemelerini / değişikliklerini küçük sürümü artırır ve geriye dönük uyumsuz API değişiklikleri ana sürümü artırır.

Bu sisteme "Anlamsal Versiyonlama" diyorum. Bu şema altında, sürüm numaraları ve bunların değiştirilme şekli, temel kod ve bir sürümden diğerine değiştirilenler hakkında anlam taşır.

Sürüm oluşturma API'nın alt kullanıcılarını etkilediğinde daha net hale getirmeye yardımcı olan bir sistemdir.

API'nız benzer şekilde açık olduğu sürece, hangi yolu seçeceğiniz çok büyük bir anlaşma değildir. Anlamsal sürümleme basittir, örneğin 3.4.2 kullanıyorsam ve 3.4.10'a yükseltmem gerekiyorsa, bunu hiçbir şey kırmadan yapabileceğimi biliyorum. Yeni sürüm 3.5.1 ise geriye dönük olarak uyumlu olduğunu biliyorum. Ve sürüm 4.0.1'in kırıcı bir değişiklik olacağını biliyorum.

Hepsi sürüm numaralarının ne anlama geldiğinin bir parçası.

@enderland Evet, temelde. BAŞLICA (PCI) .MINOR (PCI) .FEATURE.HOTFIX + YAPI. Temel olarak, yalnızca PCI (ve daha sonra şirketteki PCI derebileri) dahil olmadan 3. ve 4. bileşeni değiştirmemize izin verilir. Bana göre bu biraz uyuşmuş gibi geliyor, sürüm numarasını yönetme biçiminde haklı olduklarından emin değilim, ancak PCI ve denetim süreci hakkında başka türlü söyleyecek kadar bilgim yok.

Tamam, bu iyi. Sizin için çalışan ve ihtiyaçlarınızı karşılayan bir sisteminiz var. Versiyonlama noktası budur.

API'nız özelse (yalnızca dahili olarak bakar), sizin ve onu kullanan herkes için mantıklı olduğu sürece sürümünüzü gerçekten önemli değildir. Standart bir biçimde sürüm oluşturmanın önemi, API'nızın "bu sürümün ne anlama geldiğini" bilmesi gereken birçok tüketiciniz olduğunda önemlidir.

Rasgele bir versiyonlama sistemine sahip olmak, semantik versiyonlama gibi diğer sistemlere alışkın olan insanları karıştırır. Ancak hiç kimse, sürüm oluşturma sisteminizi, onu oluşturan kişiler dışında kullanmıyorsa - bu gerçekten önemli değil.

In 2.0.0 olan Semantik Versioning, geçerli sürümüne hayır. Sürümü XYZ formu olarak tanımlayan bir gereksinim vardır; burada X, Y ve Z, önde gelen 0'ları içermeyen negatif olmayan tamsayılardır:

Normal bir sürüm numarası, X, Y ve Z'nin negatif olmayan tamsayı olduğu XYZ biçimini ALMALIDIR ve önde gelen sıfırlar İÇERMEMELİDİR. X ana versiyon, Y minör versiyon ve Z yama versiyonudur. Her eleman sayısal olarak artar ZORUNLU. Örneğin: 1.9.0 -> 1.10.0 -> 1.11.0.

Ancak, meta veri ekleme yeteneğine aşağıdakiler için izin verilir:

Oluşturma meta verileri, düzeltme eki veya yayın öncesi sürümden hemen sonra bir artı işareti ve bir dizi nokta ayrılmış tanımlayıcı eklenerek belirtilebilir. Tanımlayıcılar sadece ASCII alfanümerik ve tire [0-9A-Za-z-] içermelidir ZORUNLU. Tanımlayıcılar boş OLMAMALIDIR. Derleme önceliği belirlenirken meta veriler oluşturulur. Bu nedenle, yalnızca derleme meta verilerinde farklılık gösteren iki sürüm aynı önceliğe sahiptir. Örnekler: 1.0.0-alfa + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp. Sha.5114f85.

Bununla birlikte, dikkat edilmesi gereken önemli bir şey, Semantik Sürüm Oluşturmanın özellikle genel bir API bildiren yazılımlar için olmasıdır:

Anlamsal Sürüm Oluşturma kullanan yazılımlar herkese açık bir API bildirmelidir. Bu API kodun kendisinde bildirilebilir veya kesinlikle dokümantasyonda bulunabilir. Ancak yapılırsa, kesin ve kapsamlı olmalıdır.

Bu, uygulama düzeyinde değil, kitaplık veya hizmetlerin geliştirilmesini destekleme eğilimindedir.

Dikkate alınması gereken önemli olan, hem dahili hem de harici kullanım için sürüm numaralarınızın ne anlama geldiğidir. Sürümler, yalnızca yazılımdaki farklılıklar hakkında iki farklı noktada konuşmanıza olanak tanıyan tanımlayıcılardır. Anlamsal Sürüm Oluşturma, kuralların etrafına koymanın bir yöntemidir, bu nedenle bir uygulamanın Anlamsal Sürüm Oluşturma kullandığını biliyorsanız, paketlerinizi güncellemek için gereken çaba düzeyini daha kolay bir şekilde belirleyebilirsiniz. Ortak bir standarda uymak iyi olabilir, ancak herhangi bir nedenle yapamıyorsanız, kullanıcılarınız için kuralları belgelemek de yeterli olmalıdır.