نسخه‌بندی نرم‌افزار
روش‌های نسخه‌بندی نرم‌افزار > شناساگرهای وابسته به توالی > اهمیت تغییر

در برخی روش‌ها، از شناسه‌های وابسته به توالی برای رساندن اهمیت تغییرات بین انتشارهای یک نرم‌افزار استفاده می‌شود. تغییرات بین دو انتشار، توسط سطح اهمیت طبقه‌بندی می‌شوند و تصمیم در مورد اینکه کدام توالی در بین دو انتشار نرم‌افزار تغییر کند به اهمیت تغییرات از انتشار قبلی بستگی دارد؛ بنابراین اولین توالی هنگامی تغییر می‌کند که مهم‌ترین و بیشترین تغییرات در بین دو انتشار رخ داده باشد و تغییرات بعدی توالی‌ها نشانگر تغییرات کم اهمیت بین دو انتشار هستند.
برای مثال، در روشی که از شناسه‌ای با چهار توالی استفاده می‌کند، اولین توالی وقتی افزایش می‌یابد که کد به ‌طور کامل بازنویسی شده باشد، در حالی که اگر در رابط کاربری یا در مستندات برنامه تغییر کوچکی انجام شده باشد شناسهٔ چهارم تغییر می‌کند.
این روش به کاربران اجازه می‌دهد تا میزان پیشرفت پروژه و همچنین میزان آزمایش‌هایی را که روی پروژه انجام شده‌ است را ارزیابی کنند. اگر تغییرات در قسمت میانی صورت گیرد، برای مثال، اگر سیر انتشار ۱٫۳ انتشاری به صورت 1.3rc4 داشته باشیم، این انتشار نشان‌دهندهٔ آزمایشی بودن این انتشار است و در حقیقت دارای تغییراتی است که لزوماً در دنیای واقعی آزمایش نشده‌اند. این روش به‌طور معمول «سطح سوم از شماره بندی» (تغییر) را میسر می‌کند:
1.3.1, 1.3.2, 1.3.3, 1.3.4... 1.4b1, ...
در اصل در انتشارهای بعدی، عدد بزرگتر (major number) وقتی افزایش می‌یابد که پرش یا جهش‌های بارزتری وجود داشته باشد، عدد کوچکتر (Minor Number) وقتی افزایش می‌یابد که تنها مشخصات کوچکی افزوده شده باشند یا رفع باگ مهمی انجام شود، و رقم تجدید نظر (Revision Number) وقتی افزایش می‌یابد که نواقص و باگ‌های کوچکی رفع شوند. برای مثال یک محصول می‌تواند دارای چنین سیری از انتشارات باشد:
۰٫۹٫۱, ۰٫۹٫۲, ۰٫۹٫۳, ۱٫۰, ۱٫۰٫۱, ۱٫۰٫۲, ۱٫۱, ۱٫۱٫۱, ۲٫۰, ۲٫۰٫۱, ۲٫۰٫۲, ۲٫۱, ۲٫۱٫۱, ۲٫۱٫۲, ۲٫۲, ...
ممکن است توسعه دهندگان از نسخهٔ ۵٫۰ با نسخهٔ ۵٫۵ جهش کنند تا نشان دهند که ویژگی‌های مهمی افزوده شده ‌است، اما این ویژگی‌ها در حد کافی نبوده ‌است که عدد بزرگتر (Major Number) را تغییر دهند.
روش متفاوت دیگر، آن است که در کنار اعداد بزرگتر و کوچکتر، از حروف الفبا برای تفکیک کردن انواع انتشار -یعنی آلفا، بتا، 'کاندیدای انتشار'- استفاده شود. یک روند انتشار که از این روش استفاده می‌کند می‌تواند شبیه به موارد زیر باشد:
۰٫۵, ۰٫۶, ۰٫۷, ۰٫۸, ۰٫۹ == 1.0b1, 1.0b2 (با کمی بهبود), 1.0b3 (با بهبودهای بیشتر) == 1.0rc1(به اندازهٔ کافی پایدار است) == ۱٫۰
اگر مشخص شود که 1.0rc1 نیاز به رفع باگ دارد، در اینصورت به نسخهٔ 1.0rc2 (بخوانید دومین نسخهٔ کاندیدای انتشار از نسخهٔ اول نرم‌افزار) تبدیل می‌شود و همین‌طور ادامه می‌یابد. مهم‌ترین ویژگی این روش آن است که اولین نسخهٔ یک سطح مشخص (بتا، RC، تولید) باید با آخرین نسخهٔ زیر انتشار آن برابر باشد: یعنی شما نمی‌توانید از آخرین نسخهٔ بتا به اولین نسخهٔ RC تغییرات جدید به نرم‌افزار اضافه کنید و همچنین از آخرین RC به انتشار نهایی نرم‌افزار. در صورت انجام چنین کاری باید یک انتشار دیگر در سطح پایینی توالی‌ها ایجاد کنید.
با این حال چون نسخه‌بندی شماره‌ها ساختهٔ دست انسان هستند می‌توان تغییرات دلخواهی را ایجاد کرد که از این اصول تخلف می‌کنند: برای مثال اولین توالی می‌تواند بین نسخه‌هایی افزایش یابد که تنها یک خط از کد آن‌ها با یکدیگر متفاوت است تا این حالت (کاذب) را به وجود آورند که تغییرات بسیار مهمی روی داده است.
دیگر روش‌ها به توالی‌های مجزا معنا می‌بخشد:
major.minor[.build[.reversion]]
یا
major.minor[.maintenance[.build]]
دوباره، در این مثال‌ها، تغییرات هر توالی از سمت چپ، نشان دهندهٔ اهمیت بیشتر و بارز بودن تغییرات در پروژه است و تعریف تمایز این توالی‌ها توسط نویسنده به ‌طور اختیاری انجام می‌شود.
در اکثر برنامه‌های تجاری اولین شمارهٔ انتشار یک محصول از نسخهٔ شمارهٔ یک شروع می‌شود.