Bir taahhüt ne zaman sürüm etiketlenmemelidir?

Bağlam: Geçenlerde Semantik Sürüm Oluşturmayı öğrendim ve pratik olarak kendi projelerim için en iyi şekilde nasıl kullanılacağını belirlemeye çalışıyorum.

Sömürücü, büyük değişiklikler, küçük değişiklikler ve düzeltme eklerini dikkate alırken, bir güncelleme ne zaman güncellenmiş bir sürümle etiketlenmemelidir? Bana öyle geliyor ki her değişiklik bu kategorilerden birine uyacak ve her değişiklik versiyonlanmalı, fakat GitHub'daki çeşitli popüler projelere baktığımda, işler böyle yürüyor gibi görünmüyor (sadece büyük projelerin sadece yüzlerce etiketle onbinlerce komisyona sahip olduğu gerçeği).

Endişeler sürüm SemVer bültenleri , değil taahhüt . Sürüm kontrol modeliniz, her bir master kararının bir sürüm olmasını gerektiriyorsa, o zaman evet, her taahhüdün değişimin derecesine göre etiketlenmesi gerekir.

Genel olarak, yine de, projeler ustada çoğunlukla istikrarlı bir ürün geliştiriyor ve desteklenmeye değer gördüğü sürümleri etiketliyor. Bunu yaptıklarında, özellikle SemVer olması gerekmeyen versiyonlama şemalarına göre etiketleyeceklerdir.

Sürüm numaraları sürümlere tahsis edilmiştir. Genel olarak her taahhüt bir tahliye olmamalıdır. Bunun birkaç nedeni var.

Öncelikle her testte "test" derken, test seviyeleri var. Bir makinede otomatik bir test ünitesinin çalıştırılması her şey yolunda ve iyidir, ancak karmaşık yazılımda muhtemelen her konuyu yakalayamaz. Bazı konular donanıma veya yapılandırmaya özgü olabilir, bazı konular, test edilebilir zorunluluklardan ziyade, insan öznel düşünceleriyle ilgili olabilir.

İkincisi, büyük sürüm numarasını çarpmak nadir görülen bir eylemdir. Temel olarak, yazılımınıza bağlı olan her şeyin, kaldırılan özelliklerden herhangi birine bağlı olup olmadığını görmek için manuel olarak kontrol edilmesi gerektiği anlamına gelir.

Bunun bir sonucu olarak, özellikleri "genel API" nize yalnızca tam (alfa / beta değil) sürümlerinde eklemelisiniz, eğer bu özellikleri uzun süredir mevcut formlarında desteklemeye hazırsanız.

Üçüncüsü, yaygın kullanımdaki sürüm sayısını azaltmak. Sabit bir dalda bile, bir dizi düzeltmeyi bir araya getirmek ve her düzeltme için bir onaylama yapmak yerine tek bir sürüm yapmak genellikle daha iyidir.

Söylemek açık görünüyor, ancak: sürüm numaralarının amacı, hangi yazılımın çalışmakta olduğunu kolayca belirlemenizi sağlamaktır.

Herhangi birinin kodun belirli bir yinelemesine erişebilmesi ve benzersiz bir tanımlayıcıyı kolayca belirleyememesi olasılığı varsa, yinelemenin benzersiz bir sürüm numarasına sahip olması gerekir. Bunu 'ilk kural' olarak görüyorum. Sonuç olarak, farklı sürümler açıkça farklı sürüm numaraları isteyecektir.

Ancak, daha fazlası devreye giriyor:

Bundan emin olmanın bir yolu, sürüm numaralarını her bir taahhütle çarpmaktır, ancak bu genellikle iyi bir fikir değildir. Göreceli olarak küçük bir değişikliğin çalışması için birkaç taahhüt / yineleme gerekebilir ve çok sayıda birikmiş değişiklik sonucunda 0.0.2 -> 0.0.2 versiyonunu görmek dış dünyaya kafa karıştırıcı olabilir. .56 çünkü biri beyaz boşluk işledi, her seferinde bir dosyayı düzeltti ve işlevsel hiçbir şeyi değiştirmedi.

"Her sürüm için bir sürüm" den "her bir işlem için bir sürüm" den yolun aşağısına ne kadar kaldı: siz, diğer kullanıcılar ve boşlukları doldurmak için hangi sistemleri kullanmak istiyorsunuz?

Şahsen küçük projeler üzerinde çalışmaya alışkınım ve başkalarının kullandığı bir sürüme ve her biri için bir çarpma sürümü olana kadar git karmalarını kullanmaktan mutluyum (ne kadar az insanın eline geçmesini beklediğim önemli değil). Ancak daha büyük şirketler ve daha büyük projelerde anlamsal sürüm numaraları dışında bir şey, ancak sürüm adayı numaralandırması gibi her işlemden daha düşük sadakat kullanılır. Bunların avantajları var ama karmaşıklık katıyor.

Master ile birleştirilen her çekme talebi versiyonlanmalıdır.

Yeni bir sürüm (en az bir düzeltme eki) olmaması gerekiyorsa, / fix / etc özelliği tam olmadığından büyük olasılıkla master ile birleştirilmemelidir.

Bununla birlikte, ekibinizin iş akışına bağlı olarak, bir sürüm olmadan master yapmak için hala birden fazla taahhütte bulunabilirsiniz. Çekme isteğinde ezilme olmayan birkaç işlem varsa (Bence olmamalıdır), yine de 10 işlem ve sadece 1 yeni sürümle sonuçlanabilir.