Sürüm numarasını ne zaman arttırmalıyım?

Okulda programlamayı öğrenmedim ve (profesyonel) bir geliştirici olarak çalışmıyorum, bu yüzden birçok temel konu bana açık değil. Bu soru, bir tanesini netleştirmeye çalışır.

Şimdi ben sorunları var varsayalım #1, #2ve #3sürümü için geliştirilmiş / düzeltilmelidir ayarlanır benim Sorunlar Tracker 1.0.0ve son (kararlı) sürümü olduğunu 0.9.0.

Sürümü 1.0.0ne zaman arttırmalıyım ? A) yukarıda belirtilen sorunlardan sadece biri kapalı mı veya b) versiyonla ilgili tüm konular 1.0kapalı mı?

Hangisini yapmanın doğru yolu? Ve doğru anlamda , şu anda sanayide kullanılanları kastediyorum.

İşyerinde nasıl yaptığımı söyleyebilirim.

Sürümlü bir paket oluşturan, test eden, etiketleyen ve çıkaran sürekli bir entegrasyon sunucumuz var. Sadece bir önceki aşamaya% 100 başarılı olursa ilerleriz.

Sürümümüz şöyle görünüyor: <Büyük Sürüm>. <Küçük Sürüm>. <Yapı Numarası>

• Tamamlanan bir hata düzeltmesi veya özellik geliştirmesi olmayan her başarılı derlem, Yapı Numarasını artırır.
• Tamamlanmış bir hata düzeltme veya özellik geliştirme ile yapılan her başarılı kurulum Minor Sürüm'ü artırır. Bu, belirli bir formatı kullanan bir onay mesajının varlığıyla otomatik olarak algılanır. Bu taahhüt mesajı otomatik olarak ChangeLog projelerine de dahil edilir.
• Her Büyük Sürüm artışı, geriye dönük uyumlu olmayan değişikliklerimiz olduğunda elle yapılır, sıfırdan veya durum bazında bir durum için yapılan diğer nedenlerden dolayı yeniden yazar.

Sürüm numaraları yalnızca harici sürümler için yazılımınızın belirli bir yapısını tanımlamanın bir yolu olduğundan sürümler için geçerlidir. Yalnızca geliştirme yapmakla meşgul ve her düzeltmeyi ayrı ayrı yayınlamıyorsanız, her düzeltme için sürüm numarasını artırma konusunda endişelenmeyin. Dış kullanıcılar ile ilgili değildir ve ekstra sürüm kayıt tutma ile kendi zamanınızı boşa harcar.

Sürekli olarak dağıtılan web uygulamaları için, symver'ı ön tarafa yerleştirerek yapı numaraları ve yapı numarası yazmayı, yani: 4.38'in sürekli entegrasyon sisteminden geldiği 2.5.3.4328. Genel beklenti, sayıların kasıtlı adımlarla değiştiği, ancak yapı sayısının gerçek benzersiz kimlik olduğu şeklindedir.

Burada göründüğü şey, konuşlandırma gününü ve ilgili svn yapı numarasını yakalamaktır:

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

Buna değer.

Diğer cevaplar zaten harika, bu yüzden sadece üstüne ekleyeceğim. Yazılımınız piyasaya sürülmediyse ve gerçekten genel sürümlere ihtiyacınız yoksa (genel olmayan sürüm VCS'nizdir), sürümünüzün sonuna " SNAPSHOT " anahtar kelimesini ekleyin . Bazı sistemlerde, özellikle bağımlılık yönetiminde, anlık görüntülerin sürüm numarası yerine anlık görüntülerin değişiklik tarihini karşılaştırdıkları için yayımlanan sürümlerden farklı davranır. Öyleyse , bir paket deposunda sabah saat 8'den bir v. 1.0.0-SNAPSHOT varsa ve yerel bir bağımlılık indiricisi saat 07: 00’nin aynı sürümüne sahipse, güncellenen bilgiyi depodan indirmesi gerekir.

Yukarıda da belirtildiği gibi, özel versiyonunuz versiyon kontrol sisteminiz (git, svn vb.) Tarafından sağlanır.

Başka bir bakış açısı olan versiyonlama teorisi hakkında yeterince söz var.

1.0.0 sürümüne ne zaman arttırmalıyım?

Cevabımı ana sürüm numarasının değiştirilmesine odaklayacağım.

Cevabım: Temelde hazır olduğunuzda. 0,9’dan 1,0’a çıkmak büyük bir şey çünkü kamuoyu algısı bir beta üründen resmi sürümlere geçeceğiniz olacaktır.

(Burada bir şirketin ticari bir ürünü olduğunu varsayacağım).

0.9 dan 1.0 a gitmeden önce birkaç soru.

Kuruluşunuzun mevcut tüm müşterilerinizi bilgilendirmek için zamanı var mı? Parti vermek. Çok fazla destek talebi alın. Ürününüzü satmak için bir hesap yöneticisi? Vesaire vesaire.

Evet, versiyonlamayı bir pazarlama aracı olarak görüyorum ve etrafınıza bakarsanız temelde endüstri standardı olduğunu görüyorsunuz.

Şirketimiz, sürüm 2.x'ten 3.0'a geçti ve büyük bir parti verdi, çok fazla vızıltı yarattı ve bu yüzden birkaç yeni müşterimiz oldu. Bazı arayüz güncellemelerinin yanı sıra, sürümler arasındaki farklar oldukça küçüktü.