Klasik anlamsal sürüm oluşturma şeması "MAJOR.MINOR.PATCH" mantıklıysa, kime dağıttığınıza ve özellikle son kullanıcıya ne zaman ve ne sıklıkta dağıttığınıza bağlıdır . Şema en çok 4.5.0 ile başladığınız kararlı sürüm "4.5" ile çalışıyorsanız yararlıdır. 4.5.1, 4.5.2 ve benzeri sürümler yalnızca hata düzeltmeleri içerirken, dahili olarak 4.6 sürümü üzerinde çalışmış olursunuz.
Örneğin, son kullanıcınıza bir "kararlı dal" sağlarsanız, ilk dağıtım için 4.5.0 ve yama eklediğinizde 4.5.1, 4.5.2 sürümünü verin. Dahili "çevik" geliştirme ve sprint dağıtımınızda, bir 4.6 sürümüne sahip olabilirsiniz, sadece "beta sürümü" olarak adlandırın. Sprint ortasında her dağıttığınızda, "4.6.beta build 123" gibi otomatik oluşturulan derleme numarasını ekleyin. Sprintiniz sona erdiğinde, ona "4.6.0" atayın ve bir sonraki sprint için sürüm numarasını dahili olarak "4.7" olarak değiştirin. ".0" ile başlamak yalnızca bir kuraldır, beta sürümlerini etiketlemek için ".0" kullanabilir ve son kullanıcılarınız için ".1" ile başlayabilirsiniz. IMHO "beta" kelimesi çok daha etkileyici ve herkese sprint'in "henüz tamamlanmadığını" söylüyor.
Her beta sürümüyle tam bir son kullanıcı değişiklik günlüğü çıkarırsanız, ancak en azından sprint sonunda değişiklik günlüğü tamamlanmalı ve son kullanıcıya bir hata düzeltmesi yaptığınızda, tarih belgeleri.
Inkscape, Firefox veya 7-zip gibi birçok açık kaynak ürününde iki ayrı dal, bir anlamsal sürüm numarasına sahip bir "kararlı" dal ve yapı numaraları veya benzer bir şeyle işaretlenmiş bir "geliştirme dalı" serbest bırakma stratejisini bulacaksınız.
Bununla birlikte, ayrı kararlı ve geliştirme dalları ile çalışmaz ve son kullanıcıya günlük olarak yeni bir sürüm yayınlarsanız, günlük sürüm numarasını da artırmanız gerekir. Böyle bir durumda, "4.5.1", "4.5.2", ... sürüm numaraları muhtemelen bireysel dağıtımlarınızı yansıtır ve hata düzeltmeleri ile diğer değişiklikler arasındaki farkı göstermez. Tamam olabilir, artık sadece klasik "anlamsal sürümleme" değil. Bu senaryoda, gerçek bir fark vermeyen 4.5, 4.6, 4.7, 4.8 sürümlerini de dağıtabilirsiniz.
Değişiklik günlüğünüzdeki girişler hakkındaki sorunuzla ilgili olarak: Son kullanıcı tarafından bir şey göründüğünde IMHO, değişikliği dağıtır etmez değiştirmez bir girişe değer. Örneğin, özellik arasında geçiş yapar ve henüz kullanıcı tarafından etkinleştirilmemiş olan yarı pişmiş bir özellikte değişiklik yaparsanız, bu bir changelog'a ait değildir. Kullanıcıda görünür bir değişiklik olmadan yalnızca yeniden düzenleme yapıyorsanız, bu bir changelog'a ait değildir. Bazı kullanıcıları etkileyebilecek bir hatayı düzeltirseniz, bu kesinlikle changelog'a aittir - ve bugfix'i dağıtırken aynı zamanda burada belirtilmelidir. Günlük veya aylık veya yıllık olarak yayınlamanızın bir önemi yoktur.