حتما نسخه بندی و نگارش‌های مختلف نرم افزارهایی را که استفاده می‌کنید، مشاهده نموده‌اید. نسخه‌های آلفا یا بتا یا نسخه بندی سالیانه یا با حروف و اعداد خاص. با این حال همه نرم افزار‌ها علاوه بر عناوین متعارف، یک نسخه بندی داخلی عددی، شمار‌ه‌ای هم دارند. بسته به حجم و اندازه نرم افزار‌ها، ممکن چرخه انتشار نرم افزار‌ها متفاوت باشند. سیاست عرضه نرم افزار در هر شرکت هم متفاوت است. مثلا شرکت مایکروسافت برای عرضه ویندوز ابتدا نسخه بتا یا پیش نمایش آن را عرضه نموده تا با دریافت بازخورد‌هایی از استفاده کنندگان، نسخه نهایی نرم افزار خود را با حداقل ایراد و خطا عرضه نماید. البته این بخاطر بزرگی نرم افزار ویندوز نیز می‌باشد اما شرکت ادوبی اکثرا هر یکی دو سال بدون عرضه نسخه‌های قبل از نهایی یک دفعه نسخه جدیدی را رسما عرضه می‌نماید
چرخه انتشار نرم افزار از زمان شروع کد نویسی تا عرضه نسخه نهایی می‌باشد که شامل چندین مرحله و عرضه نرم افزار می‌باشد.
در دنیای مدیریت نرم‌افزار یک موقعیت ناخوشایند به نام "جهنم وابستگی" وجود دارد. هر چه سیستم شما بزرگ‌تر میشود و هر چه کتابخانه‌های بیشتری به نرم‌افزار خود می‌افزایید، به همان میزان احتمال گرفتار شدن شما در این دام بیشتر خواهد شد.
در سیستم‌هایی با وابستگی بسیار زیاد، انتشار نسخه جدید کم کم تبدیل به یک کابوس میشود. اگر وابستگی شما به کتابخانه‌ها بسیار زیاد و پیچیده باشد، شما در معرض خطر قفل شدن انتشار نسخه جدید قرار می‌گیرید (عدم توانایی برای بروزرسانی یک کتابخانه بدون انتشار نسخه جدید کتابخانه‌های وابسته). اگر وابستگی شما به کتابخانه‌ها خیلی بی‌قاعده و کم باشد، شما ناگزیر توسط نسخه‌های بی‌قاعده درگیر می‌شوید. هنگامی که مشکل قفل شدن انتشار نسخه جدید و/یا انتشار نسخه‌های بی‌قاعده شما را از حرکت مناسب و خوب برای تکمیل پروژه‌تان بازمی‌دارد، در واقع شما در "جهنم وابستگی" قرار دارید.
به عنوان یک راه حل برای حل این مشکل، یک مجموعه ی ساده از قوانین و الزامات که چگونگی طراحی شماره های نسخه و افزایش آن را دستور میدهد را پیشنهاد می‌کنیم. برای کار کردن این سیستم، شما ابتدا نیاز به اعلام API عمومی دارید. این خود ممکن است شامل مستندات و یا اجرای کد باشد. علی رغم آن، مهم است که این API روشن و دقیق باشد. هنگامی که API عمومی خود را تعیین کردید، تغییرات برنامه شما بر روی نسخه API عمومی تاثیر خواهد داشت و آنرا افزایش خواهد داد. بر این اساس، این مدل نسخه‌بندی را در نظر بگیرید: X.Y.Z یعنی (Major.Minor.Patch). رفع حفره‌هایی که بر روی API عمومی تاثیر نمی‌گذارند، مقدار Patch را افزایش می‌دهند، تغییرات جدیدی که سازگار با نسخه قبلی است، مقدار Minor را افزایش می‌دهند و تغییرات جدیدی که کاملا بدیع هستند و به نحوی با تغییرات قبلی سازگار نیستند مقدار Major را افزایش می‌دهند.
عددی که برای نسخه نرم افزار توسط روش Semver انتخاب میشود از سه قسمت X.Y.Z تشکیل شده است
که به شکل Major.Minor.Patch هم می توان از آن نام برد .
عدد اول Major یا X زمانی اضافه میشود که تغییرات گسترده ای صورت گرفته باشد و شاید از API جدید استفاده شده باشد که نسخه قبلی آن را ساپورت نکند .
عدد دوم Minor یا Y زمانی افزوده می شود که قابلیتی به نرم افزار اضافه شده باشد که نسخه قبلی هم آن را بدون مشکل می تواند اجرا کند .
عدد سوم Patch یا Z زمانی اضافه می شود که ایرادها را برطرف کرده باشید
نسخه هایی که منتشر می شود تا بازخوردها دریافت شده و نهایتا نسخه نهایی عرضه گردد.
نسخه هایی که بعد از انتشار رسمی عرضه می شود
همان تصویر و روش بالا را در نظر بگیرید در انتها باید با استفاده از کارکتر “-” یکی از کلمه های Alpha ( عرضع اولیه ) و Beta ( عرضه ثانویه ) و در نهایت rc ( پیش از انتشار )
هر کدام از کلمه های بالا هم به نوبه خود احتمال ارتقا تا قبل از نسخه بعندی دارند به عنوان مثال
1.0.0-Alpha.17
1.0.0-rc.12
نسخه های بالا به ترتیب یعنی عرضه اولیه (آلفا ) که ۱۷ مرتبه اصلاح شده و نسخه پیش از انتشار رسمی که ۱۲ بار رفع خطا شده .
نکاتی که باید در نسخه بندی حتما رعایت شود :
منابع:آفیس‌باز - قلم مجتبی کاویانی
