Bir proje çatallandı, sürüm numaram nerede başlıyor?

Bir projeyi çatalladım ve çok değiştirdim. Bu çatal burada sadece küçük bir özellik değişikliği değil ve orada gömülü bir hata düzeltmesi değil, oldukça önemli bir değişiklik. Çekirdek kodun yalnızca çoğu paylaşılıyor.

Bu projeyi v2.5.0'da çatalladım. Bir süredir çatalımı v3.0'da versiyonlamaya başladım. Ancak bunun doğru yol olup olmadığından emin değilim, çünkü bu proje v3.0'a ulaştığında işler kafa karıştırıyor. Ancak v1.0 veya v0.1'de başlamak istemiyorum çünkü bu, bir projenin bebeklik, istikrarsızlık ve yeniden hatırlanmama anlamına geliyor. Çekirdek kodun çoğu çok rafine ve kararlı olduğu için bu doğru değildir.

Ne yapacağım konusunda gerçekten kayboldum, bu yüzden burada soruyorum: Bu tür bir durumla başa çıkmanın standart yolu nedir? Çatalların çoğu baştan başlar mı, sürüm numaralarını çarpar mı yoksa farkında olmadığım başka bir şey yapar mı?

Gördüğüm çoğu çatal 1.0 sürümünden başlıyor. Ancak, çatalınızın adını da değiştirdiğinizi varsayalım, bu yüzden v3.0'dan yeni başladıysanız neden karışıklık olacağını bilmiyorum.

Yapacağım şey, projenin adını değiştirmek, sürüm 1.0'ı yayınlamak ve projenin başka bir projenin çatalı olduğunu açıkça belirtmektir. Bu yaklaşımla ilgili bir karışıklık olacağını düşünmüyorum.

"1.0" etiketi hakkında gerçekten endişeleniyorsanız, 1.0 sürümünden kısa bir süre sonra 2.0 sürümünü yayınlamanız yeterlidir ...

Kendi yol haritanıza sahip olun ve orijinal sürümün numarasından başlayarak yapıştırın, ancak orijinal ürünün geçerli sürümüyle yarışmaya çalışmayın.

Projenizin orijinal projeyle ilgili olup olmayacağını (ve ne kadar olduğunu) düşünmek isteyebilirsiniz. Yeni özellikleri orijinal projeden projenize taşımayı planlıyorsanız, sürüm numaralarınızı orijinalin sürümleriyle eşleştirmeyi düşünebilirsiniz.

Örnek olarak MySQL'in bir çatalı olan MariaDB'yi kontrol edin. Bunu MySQL için 'bırakma' yerine tutmak istiyorlar, bu nedenle örneğin MariaDB 5.2, MySQL 5.2'nin tüm özelliklerine sahip.

Bkz. Http://kb.askmonty.org/v/mariadb-versus-mysql

Not: Bu yanıt gönderildiği için MariaDB, MySQL'den önemli ölçüde sapmıştır ve şimdi kendi sürüm oluşturma şemasını takip etmektedir.

0.1 bebeklik dönemini gösterebilir, ancak 1.0+ sürümü stabil anlamına gelir. Ana sürüm numaralarındaki bir artış, örneğin 2.0, 3.0, genellikle büyük bir özellik değişikliğine işaret eder.

Örneğin

• Uygulamamın 1.0 sürümü, kurulumla test komut dosyalarını çalıştırmak için bir araçtı,
• Sürüm 2.0, test komut dosyaları ile ortam kurulum komut dosyaları arasındaki ayrımı kaldırdı,
• Sürüm 3.0, akış şemaları olarak komut dosyaları yazmak için bir GUI ekledi. Tanınabilir derecede farklı ürünlerdir, ancak Sürüm 1 bile tamamen kararlı vb. Çalışan bir üründür. 2 ve 3 sürümleri ortaya çıktı çünkü bu büyük değişikliklerin iyi olacağına karar verildi. Bu büyük değişiklikleri istememiş olsaydık ve hata düzeltmeleri yapmaya devam etseydik. Küçük sürüm numaraları 1.10,1.20 vs yükselirdi ve bu iyi olurdu.

Diyorum ki büyük sürüm numaraları olgunluk belirtmez, onlar büyük özellik kümeleri gösterir. Şimdi bu, ürününüzün sürüm numarasının nasıl yapılacağı konusunda biraz teğetti.

Daha önce gördüğüm, sessizce sevdiğim, 1.0'dan (veya gerçekten tercih ederseniz 3.0'dan) tekrar sürümlendirmeye başlamak ve daha sonra orijinalin hangi sürümünün çekildiğini söyleyerek parantez içinde.

• Başlangıçta: " MyFork v1.1 (OrigProg v3.0 tabanlı)
• MyFork için yapılan bazı iyileştirmeler: MyFork v1.3 (OrigProg v3.0 tabanlı)
• OrigProg büyük bir sürüm yayınladı ve MyFork çekti ve birleştirdi: MyFork v2.1 (OrigProg v4.0 tabanlı)
• MyFork'ta bazı büyük değişiklikler yaptı (muhtemelen OrigProg ile bir daha kolayca birleştirilemeyecek): MyFork v3.0 (OrigProg v4.0 tabanlı)

Mümkünse, çatalınızı orijinal projeye geri getirin. Bunu yeterince vurgulayamıyorum.

Sürüm numaralarınızı geri yükledikten sonra çatalını eklediğiniz numarayı ve bir tarih sonekini kullanın.