Yazılım sürüm numarası olarak tarih

Yazılım geliştiriciler, tarihi tarih numarası olarak kullanmazlar, ancak YYYYMMDD formatı (veya varyansları) kullanmak için yeterince sağlam görünüyor. Bu programda bir sorun mu var? Yoksa yalnızca sınırlı türdeki yazılımlar için de geçerlidir (şirket içi yapımlar gibi)?

Bu, kullanıcı gereksinimlerinin yanı sıra yazılım ve geliştiricilerin gereksinimlerini de göz önünde bulundurmanız gerektiğinden, birkaç farklı açıdan bakmak zorunda kalacağınız bir şeydir.

Genel olarak, müşterileriniz daha yeni bir şey çalıştırdıklarını bildikleri sürece (yani, Product 2012, Product 2010'dan daha yenidir) ve bildiklerini bildikleri sürece, yazılımın sürüm numarasının ne olacağını çok fazla önemsemez. konuşlandırılabilecek yamalar varsa günceldir (örn. Product 2012, Update 10). Bu nedenle, müşteri markaları açısından, adlandırılmış sürümleri (örneğin, Windows XP, Windows Vista) ve ardından kullanıcılar tarafından kurulabilecek katı bir dizi yamayı tercih etme eğilimindeyim.

Bununla birlikte, kullanıcı için kolay olan şeyleri kontrol eden bir yazılım yazmak, başlık altında kod yazmayı çok daha zor hale getirme eğilimindedir. Bu yüzden, basit bir Major.Minorversiyon şemasını tercih etme eğilimindeyim, çünkü bir şeyin aşağıdaki gibi güncel olup olmadığını kontrol etmek için basit bir sayı karşılaştırması yapabilirsiniz:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

Bununla birlikte, biraz bağlamda koymak gerekirse, genellikle yukarıdaki sistemin başarılı bir şekilde çalışmaya devam etmesini sağlayan küçük sayının (yani 1.1024) ne kadar büyüğünü umursamıyorum. Genel olarak, revizyon rakamları sadece iç gelişimin ilgisini çekmektedir ve aslında onları gerçekten takip etmeleri gereken bir sayı vermenin ötesinde şeyleri etkilediğini görmedim bile.

Bununla birlikte, yukarıdaki iki şema gerçekten sadece sürekli dağıtımın kullanıldığı ortamlar için geçerli değildir (yani Yığın Değişimi), ki Yığın Değişimi üzerinde kullanıldığı gibi bir revizyon numarası izleyen bir tür tarihi tercih etme eğilimindeyim. Siteler. Bunun nedeni, sürümlerin sürekli dağıtım ortamında çok sık değişeceği ve aynı gün içerisinde kodun birden fazla sürümünün bulunabileceği ve revizyon numarasını doğrulayan birden fazla versiyona sahip olabilirsiniz. daha da fazla. Teoride, sadece revizyon numarasını her şey için kullanabilirsiniz, ancak şu anki tarihi kullanmak, konuları tartışmayı kolaylaştıracak ana kilometre taşlarını dahili olarak takip etmenizi sağlar.

Tarih kullanılmasındaki sorun, şartnamelerin, verildiği tarih yerine sayım numaralarına karşı yazılmasıdır.

"Bu işlevsellik parçası sürüm 1'den kaynaklanıyor. Diğer işlevsellik parçası sürüm 2'den kaynaklanıyor."

Yayınlanma tarihi kaçırılabildiğinden, özelliklerde bir tarihe atıfta bulunamazsınız.

Önceden tanımlanmış farklı sürümlere ihtiyaç duyan resmi bir işleminiz yoksa, tarihleri ​​kullanmak iyi; karışıma başka bir numara eklemeniz gerekmez.

Sürüm numaraları , içerikleri spesifikasyonlarla bağlantılı olduğundan tarih içermesi muhtemel değildir.
Yapı numaralarının , tarihleri yapı içerdiği zamanla bağlantılı olduğu için tarih içermesi muhtemeldir.

Bu yaklaşımın tanımladığınız gibi faydaları olmasına rağmen, bir sürüm numarası olarak tarih kullanırsanız bazı dezavantajlar vardır:

• Tarih tabanlı sürümler düz. V2.1.3 ile sürüm numarasını, alt sürüm numarasını ve alt sürüm numarasını görebilirsiniz. 20110119 ile yalnızca ne zaman yazıldığını görebilirsiniz. Sen olabilir grup aya göre tarih tabanlı sürümleri, ama yine de bir şey söylemezdim. Birkaç ay boyunca küçük hata düzeltmeleri yapabilir ve ardından iki hafta boyunca süren ağır kodlamalar ciddi bir sürümle sonuçlanabilir. Tarihler size söylemez, normal sürüm numaraları yapar.

• Sürümü gerçekten günlük olarak değiştirmeniz ve muhtemelen sürüm numarasıyla değiştirmeniz gerekiyorsa, bu sürüm uygun bir sürüm sürecinizin olmadığını gösterebilir, ancak bunun yerine herkes çılgınca değiştirir ve istediği zaman üretim sunucularına tanıtır. Eğer öyleyse, bu süreçte bir probleminiz var ve farklı versiyon numarası şemaları kullanmak sorunu çözmeyecektir.

Sürümler genellikle yazılımın belirli bir sürümünün öncekinden ne kadar farklı olduğu hakkında bilgi vermek için kullanılır. Mesela, eğer Acme’in 1.0’tan 2.0’ına yükseltirseniz, teoride büyük değişiklikler olan bu büyük bir yükseltme.

1.0'dan 1.1'e yükseltme ise küçük bir yükseltmedir ve teoride küçük, artan değişiklikler ve hata düzeltmeleri gerçekleştirir.

Bir karışım kullanabilseniz de, bunun tarih biçiminde gösterilmesi zor olacaktır. Örneğin, v1.0.YYYY.MMDD

Diğer cevaplardan gelen iyi fikirleri tekrar etmeden, henüz ele alınmayan bir sorunum var.

Çatal yaparsanız, geriye dönük uyumluluk için eski bir sürüm ile uyumsuz bir modernizasyon için yeni bir sürüm arasında, sürüm numaralarıyla ayırt edemezsiniz.

Örneğin, Linux çekirdeği 2000 yıllarında bugün hala desteklenen ve 2.4.199 olarak kabul edilen eski 2.4.x dalına atıldı, yeni sürüm ise uzun yıllar 2.6, eski sistemler için, ancak en yeni çekirdekler için 3.2.

Sürümlerinizle ilgili belgeleriniz varsa, bilgileri iki katına çıkaracak ve insanlara söyleyeceksiniz, 20120109 sürümünün 2012'de 01 / 09'da geldiğini. Mh. Ancak, bir son dakika hata tespiti varsa ve bir sürüm için bir sürüm ertelenirse, ancak adın belirtildiği belgeler zaten hazırdır, belki de basılır, basın bilgileri çıkar. Şimdi 20120109 versiyonunun 2012/01/13 tarihine ulaşması halinde sorunlu olan bir tutarsızlığınız var.

SQL'de, kimliklerin anlamsal bilgi taşıması gerekip gerekmediği sorusu sıkça tartışıldı ve sonuç her zaman: cehennem gibi kaçın! Gereksiz bir bağımlılık yaratıyorsunuz. Faydası olamaz.

04/10 şemasına sahip Ubuntu, 6.04 sürümünün geciktiği ve 6.06 olduğu 2006 yılında sorun yaşadı. 3000 yılında yakında bir sonraki sorun olacak! :)

Tarihi gerçekten sürüm olarak kullanan birçok yazılım paketi var. Ubuntu, sürümlerinin YY.MM olduğu akla geliyor. Ve Microsoft Office ürünleri için yapı numaraları da yapı tarihinin bir kodlamasıdır. Jeff Atwood , bu öneri dahil, sürüm numaralandırması hakkında bir Kodlama Korku blog yazısı yazdı :

Mümkün olduğunda, özellikle ürünlerin genel adlarında sürüm numaraları yerine basit tarihleri ​​kullanın. Ve kesinlikle, pozitif olarak sürüm numaralarını dahili olarak kullanmak zorundaysanız, yine de tarihleri ​​belirtin: sürüm numaranızda bir yerin tarihini kodladığınızdan emin olun.

Kanımca, tutarlı olduğunuz ve bir yapı versiyon numarasından (her ne olursa olsun) gidebileceğiniz ve bu yapıya giren tüm eserleri versiyon kontrol sisteminizden hatırlayabildiğiniz sürece farketmez. Kullanıcılar genellikle sürüm bilgisini umursarlar, bunun yerine sistem tarafından sağlanan işlevleri önemserler. Sürüm bilgisi sadece geliştiriciler için gerçek değerdir.

Anlamsal versiyonlamayı kullanın - bu şekilde, kodun kendisini incelemeye gerek kalmadan sürümler arasında yapılan değişikliklerin bir tür fikrini elde edersiniz: http://semver.org/

Sürüm numaralarını kullanmak, değişimin ne kadar BÜYÜK olduğunu göstermenin bir yoludur

Örneğin 2.4.3, sürüm 2'nin tüm sistemdeki en büyük değişiklik olduğu anlamına gelebilir. .4 küçük bir güncellemedir. ve son 0,3 bu sürüme küçük bir hata düzeltmedir. Bu sayede her versiyon arasında ne kadar değiştiği kolayca farkedilebilir.

Birçok kişinin hala sürüm numarası olarak tarihleri ​​veya SCM revizyon numaralarını kullandığını ve bu sürüm için neyin kapsamının ne olduğuna dair destekleyici notları ve dokümantasyonu izleyebilmeniz için bir yolunuz olduğu sürece hala sayıları kullandığımı söyledim.

Burada zaten bazı iyi cevaplar var, ancak tarihleri ​​kullanmanın mükemmel bir anlam ifade ettiği bir durumu belirtmek isterim: kodun sık sık güncellenmesi muhtemel olan küçük kütüphaneler veya kod parçacıkları, ancak bir önceki sürümün dramatik olarak farklılık göstermeyen küçük bitlerinde bir.

Başka bir deyişle, gerçek bir "sürüm numarası" olmayan, ancak temel olarak bir günlük yarı depo dökümü durumlarından söz ediyorum.

Bu tür şeylerle karşılaştığımda, genellikle belirli bir sürümden ziyade nispeten güncel bir script / lib kullandığımı bilmem benim için daha faydalı olduğu için seçimi memnuniyetle karşılıyorum.

Sürüm numarası olarak Tarihler pazarlama için iyidir. İnsanlar "Windows NT 5.0" kullanıyorsa, eski olduğunu fark etmeyebilirler. Ancak, insanlar hala "Windows 2000" kullanıyorsa, bunun anında 12 yıllık bir işletim sistemi olduğunu ve yükseltmeleri için teşvik edildiğini anlayacaklar.

Ancak, "büyük" ve "küçük" güncellemeleri ayırt etmeyi zorlaştırır.

Sürüm Numaraları Olarak Tarihlerin Kullanılmasıyla İlgili Sorun

Buradaki cevaplar iyidir, ancak tarihleri ​​kullanma konusunda bu sorunu ele alan birini görmedim: Kullanıcı ne sıklıkta değişiklik yapıldığını belirleyemiyor.

Söylemeye çalıştığım şey, Windows 3.1 ve Windows 7'nin birbirinden çok uzak olduğunu ve belki de uyumsuz olduğunu söyleyebilirim. Windows 95 ve Windows 2000 bana ürünün tanıtıldığı yıldan daha fazla bir şey söylemedi.

Örneğin, Python ile 2.7.2 sürümünün 2.4.6'dan geldiğini biliyorum. Daha fazla bakarsam, 19 Aralık 2008'de 2.4.6 sürümünün yayınlandığını görüyorum; ve bu sürüm 2.7.2, 11 Haziran 2011'de yayınlandı. Bundan, bir ürünün kararlılığı (örneğin, salınım sıklığı) hakkında bir fikir oluşturabilirim.

Bunun yerine, Python çıkış tarihlerini kullandıysa, bu ürünlerin nasıl bağlanabileceğini bilemiyorum. Ayrıca, Python 3.1.4 11 Haziran 2011'de de piyasaya sürüldü (Python 2.7.2 ile aynı).

Kısacası, tek başına tarih-versiyonlamanın değerli olduğunu düşünmüyorum.

Bu fikri sevmiyorum, zaten başkaları tarafından tarif edilen sebeplerden dolayı. Sadece major.minor.bugfix şemasını kullanın - çoğu insanın bu şekilde yapmasının bir nedeni var.

Ancak ne yaparsanız yapın: Bir sürüm adlandırma şeması seçin ve buna bağlı kalın . Her sürümde programı değiştirdikleri Windows gibi yapmayın. Ve Android gibi yapmayın; her sürüm bir API sürüm numarası (8), pazarlama amaçlı bir sürüm numarası (2.2) ve aptal bir isim (Froyo).

Sürüm Olarak Tarih

Ürününüz satılmadıysa, sadece tarihi kullanmak iyi ve muhtemelen kullanışlıdır. Satıyor ve müşterilere yükseltiyorsanız, belirli özelliklere sahip bir model satın almak istiyorlar. Bu modelin açık bir adı varsa, yükseltme yapmak için satış yapmak çok daha kolaydır, ne olduğu hiç önemli değil ama örneğin, 2012 Ocak 20th Ford Otomobili kimseyi gerçekten satın alamazsa, Kia Modelini ne olursa olsun istiyorlar. Aynısı yazılım için de geçerlidir. Sert bir model adı ve sürümü vermek eskiden farklı özelliklere sahip olduğu anlamına gelir. Benim için sadece bir randevu yapmaz, o zaman yaptığımı söylüyor, yeni özelliklere sahip olmayabilir.

Kullandığımız Şema

Sistemimizin yukarıdaki gibi net bir marka yarattığını iddia etmedim. Şimdi dört bölümden oluşan bir şema kullanıyoruz. Sürüm numarası, durum, tarih ve sağlama toplamı.

1200_GLD_120120_F0D1

Bu, üste geçebilir ancak mühendislerimizin kullanabileceği 1200 sürümünün yapısının birkaç versiyonuna sahip olmamıza izin verir ve aralarında tarihe göre farklılık gösteririz. Devlet bir iç test sürümünü, müşteri yama inşa veya altın bırakma olup olmadığını söylersiniz. Sağlama onlar aslında bizim dağılımından doğru yüklediğini doğrulamak için bir mühendis veya müşteriyi tanır, yenidir.

Yani bir dizi olabilir

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

Biz sadece normal olarak müşterinin "12" büyük sürüm numaralarına atıfta bulunuruz, ancak bir müşterinin Düzeltme'ye ihtiyaç duymadıkça en son 12 altın sürümünü elde edeceğiz (1200_GLD_120120_F0D1).

Bazı müşterilerin ürününüzün ikinci sürümünü kullandıklarını, bazılarının ise üçüncü sürümüne yükseltme yaptığını ve bu yükseltme işleminin hafifçe alınan bir karar olmadığını varsayalım.

Diyelim ki ikinci versiyonun son versiyonu 2.3.2 ve üçüncü versiyon 3.0.3'te. Şimdi kesinlikle düzeltilmesi gereken bir güvenlik açığı buluyorsunuz, bu nedenle aynı gün 2.3.3 ve 3.0.4 yayınlıyorsunuz. Çıkış tarihinin tamamen alakasız olduğunu görebiliyor musunuz? 2013'te iki numaralı sürümde çalışmayı durdurmuş ve o zamandan beri yalnızca bazı önemli hata düzeltmelerini yayınlamış olabilirsiniz. Tarih, sürüm numarasına göre önemli değil.

Bence harika çalışıyor. Bazı dahili yazılımlar (yyyy.mm.dd) ve yayımladığım bazı açık kaynaklı yazılımlar için kullanıyorum.

Her durumda işe yaramayabilir.

Teknik olarak Sürüm numarası için tarih kullanamaz, ancak müşteri için tarih numarası gösterebilir. Örneğin, macOS 16.7.23 --- şu anlama gelir: 23/7/2016

Bence teknoloji sorun değil, sorun şu ki nasıl hissettiriyor? Eğer yazılımı canlı tutabilecek tarih numarası kullanıyorsanız, yaşıyorsanız, doğum günü numarası olan bir adam gibi. Her yıl büyüyoruz, Yazılımla aynı şekilde büyümeye devam ediyor.

Bina numarası makine gibi görünüyor, makine yok, hayat yok, hayat yok.