Erken sürüm numaraları yeni ürünler için nasıl çalışır?

Şu anda bir arkadaşım için küçük bir masaüstü uygulaması yazıyorum, ancak öncelikle kendim için bir öğrenme deneyimi olarak yapıyorum. Eğitimli olma ve doğru yolu yapma ruhu içinde, bu uygulama için sürüm numaralarına sahip olmak istiyorum.

Araştırmam bu ilgili sonuçları getirdi

• Hangi "sürüm adlandırma kuralı" kullanıyorsunuz?
• Dosyalarınızı nasıl sürümlendirirsiniz (Sürüm Numaraları)
• Bir proje çatallandı, sürüm numaram nerede başlıyor?

ancak hiçbiri alfa, beta, tahliye adayı ve c. 1.0'ın altındaki sürüm numaraları için kurallar nelerdir? Bir süre devam edebileceklerini biliyorum; örneğin, PuTTY en az on yıldır var ve hala sadece 0.60 beta sürümündedir.

Gerçekten projeye bağlı; bazı projeler 1.0 sürümünü bile yayınlamıyor.

MAME geliştiricileri emülatör programlarının 1.0 sürümünü yayınlamayı düşünmüyorlar. Argüman asla gerçekten "bitmeyecek" çünkü her zaman daha fazla arcade oyunu olacak. Sürüm 0.99'u sadece sürüm 0.100 (küçük sürüm 100> 99) izledi. Benzer şekilde Xfire 1.99'u 1.100 izledi. 6 yıllık geliştirmenin ardından, eMule henüz 0.50 sürümüne bile ulaşmadı. ^{Wikipedia'da yazılım sürümü oluşturma}

(Kullanmaya başladığım) sürümleri numaralandırmanın popüler bir yöntemi Semantik Sürüm Oluşturma'dır .

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.

Bazı alıntılar size nasıl çalıştığı hakkında daha fazla fikir vermek ve / veya bazı sorularınızı cevaplamak için:

1.0.0 sürümünü ne zaman yayınlayacağımı nasıl bilebilirim?

Yazılımınız üretimde kullanılıyorsa, muhtemelen 1.0.0 olmalıdır. Kullanıcıların bağımlı olduğu kararlı bir API'nız varsa, 1.0.0 olmalısınız. Geriye dönük uyumluluk hakkında çok endişeleniyorsanız, muhtemelen 1.0.0 olmalısınız.

Bu, hızlı gelişimi ve hızlı yinelemeyi cesaretlendirmiyor mu?

Başlıca sürüm sıfır hızlı gelişme ile ilgilidir. API'yı her gün değiştiriyorsanız, hala 0.xx sürümünde veya bir sonraki ana sürümde çalışan ayrı bir geliştirme dalında olmalısınız.

Genel API'daki en küçük geriye dönük uyumsuz değişiklikler bile büyük bir sürüm yumru gerektiriyorsa, 42.0.0 sürümüne çok hızlı bir şekilde ulaşmayacak mıyım?

Bu sorumlu bir gelişme ve öngörü sorunudur. Çok fazla bağımlı koda sahip yazılımlara uyumsuz değişiklikler hafifçe tanıtılmamalıdır. Yükseltme için yapılması gereken maliyet önemli olabilir. Uyumsuz değişiklikleri yayınlamak için büyük sürümleri çarpıştırmanız, değişikliklerinizin etkisini düşüneceğiniz ve maliyet / fayda oranını değerlendireceğiniz anlamına gelir.

Ayrıca "alfa", "beta" vb. Sürümlerin nasıl belirtileceğine ilişkin kurallar da vardır. Ayrıntıları http://semver.org/ adresinde bulabilirsiniz .

[Düzenle] Bir başka ilginç sürüm numaralandırma düzeni MongoDB kullandığı :

MongoDB geliştirme sürümleri için tek sayılı sürümleri kullanır.

MongoDB versiyonunda 3 numara vardır: ABC

• A ana versiyonudur. Bu nadiren değişecek ve çok büyük değişiklikler gösterecektir.
• B sürüm numarasıdır. Bu, geriye dönük uyumluluğu bozabilecek özellikler ve şeyler dahil birçok değişikliği içerecektir. Bs bile istikrarlı şubeler olacak ve tek Bs geliştirilecek.
• C, revizyon numarasıdır ve hata ve güvenlik sorunları için kullanılacaktır.

Örneğin:

• 1.0.0: ilk GA sürümü
• 1.0.x: 1.0.x hata düzeltmeleri - yükseltilmesi şiddetle tavsiye edilir, çok az risk
• 1.1.x: geliştirme sürümü. bu, tamamlanmayan yeni özellikleri içerir ve devam eden çalışır. Bazı şeyler 1.0'dan farklı olabilir
• 1.2.x: ikinci GA sürümü. bu 1.1.x sürümünün doruk noktası olacaktır.

Ben bir "standart" olduğunu sanmıyorum.

Serbest Bırakma Adayları için, genellikle "[sürüm] RC 1" vs. olan bir sözleşme vardır.

Ürününüzün çok erken bir sürümünü yayınlıyorsanız - özellik tam olmayan bir sürüm - o zaman "0" sürümü ile gitmek isteyebilirsiniz. Bu şekilde, özellik kümenizi doldururken sürümü zamanla artırabilirsiniz.

Tam sürüm yayınlamaya yakın olduğunuzu düşündüğünüzü belirtmek için, zaman sınırlı sürümler için "Alfa" ve "Beta" yı kullanırım.

Yazılım Sürümü hakkında bir Wikipedia sayfası var . 1.0 öncesi sürümleri paylaşmak için Apple ve diğerleri tarafından kullanılan kural iyi çalışır: major.minor.maintSrev burada S yayın öncesi sürümler için sahne göstergesidir: d = geliştirme, a = alfa, b = beta, rc = serbest bırakma adayı. Yani ilk dahili sürümünüz 1.0.0d1 olabilir.

Tamamen dahili revizyonlar için zaman damgası yeterlidir.

Her geliştirici çoğunlukla hangi standardı kullanacaklarına karar verir. Genel olarak, ondalık noktasının solundaki sayılar, ortalama kullanıcı tarafından farkedilebilecek büyük revizyonları gösterir (örn. İşlevsellik veya arayüz değişiklikleri, vb.). Ondalık noktasının sağ tarafında bu, genel işlevselliği ve tasarımı çok fazla değiştirmeyen, ancak programın kendisi hakkında bir şey değiştiren bir değişiklik / modifikasyon / ekleme olacaktır (yani, aynı şeyi yaparken veya sabitlerken bir işlevi daha hızlı hale getirme) bir güvenlik sorunu). Daha sonra, ondalık noktalar eklerseniz, bunların sağındaki sayılar gittikçe daha küçük ve daha küçük değişiklikleri gösterecektir (yani küçük hata düzeltmeleri / güvenlik sorunları ve benzeri).

Diğerlerinin söylediği gibi, kesin bir standart yok gibi görünüyor. Kuruluşumuz aşağıdaki gösterimi kullanır:

Sürüm 1.0 ---> 2.0 (Ürüne eklenen yeni / geliştirilmiş bir özellik)

Sürüm 1.0 ---> 1.1 (Ürüne orta düzeyde yeni / geliştirilmiş özellik eklendi)

Sürüm 1.0 ---> 1.001 (Hata Düzeltmeleri)

"Sürüm 1.0" kilometre taşı, deneyimli bilgisayar kullanıcıları için çok önemlidir, çünkü programın yapıldığı ve beklendiği gibi çalıştığı anlamına gelir . "0.something" sürümündeki herhangi bir şey, programcıların kendilerinin programın henüz yapılmadığını düşündüklerini ima eder .

"0.1", "0.2" ... sürüm numaralarını işlevsellikte büyük başarılar elde etmek için tutabilir ve daha sonra genellikle yeterince ince taneli bir tarih ve zaman damgası olan bir yapı numarasıyla alt kümeye ayarlayabilirsiniz.