چرخه انتشار و نسخه‌بندی نرم افزار - SemVer برای نسخه‌بندی

حتما نسخه بندی و نگارش‌های مختلف نرم افزار‌هایی را که استفاده می‌کنید، مشاهده نموده‌اید. نسخه‌های آلفا یا بتا یا نسخه بندی سالیانه یا با حروف و اعداد خاص. با این حال همه نرم افزار‌ها علاوه بر عناوین متعارف، یک نسخه بندی داخلی عددی، شمار‌ه‌ای هم دارند. بسته به حجم و اندازه نرم افزار‌ها، ممکن چرخه انتشار نرم افزار‌ها متفاوت باشند. سیاست عرضه نرم افزار در هر شرکت هم متفاوت است. مثلا شرکت مایکروسافت برای عرضه ویندوز ابتدا نسخه بتا یا پیش نمایش آن را عرضه نموده تا با دریافت بازخورد‌هایی از استفاده کنندگان، نسخه نهایی نرم افزار خود را با حداقل ایراد و خطا عرضه نماید. البته این بخاطر بزرگی نرم افزار ویندوز نیز می‌باشد اما شرکت ادوبی اکثرا هر یکی دو سال بدون عرضه نسخه‌های قبل از نهایی یک دفعه نسخه جدیدی را رسما عرضه می‌نماید

چرخه انتشار نرم افزار:

چرخه انتشار نرم افزار از زمان شروع کد نویسی تا عرضه نسخه نهایی می‌باشد که شامل چندین مرحله و عرضه نرم افزار می‌باشد.

1. Pre-alpha
   این مرحله شامل تمام فعالیت‌های انجام شده قبل از مرحله تست می‌باشد. در این دوره آنالیز نیازمندیها، طراحی نرم افزار، توسعه نرم افزار و حتی تست واحد باشد. در نرم افزار‌های سورس باز چندین نسخه قبل از آلفا ممکن است عرضه شوند.
2. Alpha
   این مرحله شامل همه فعالیت‌ها از زمان شروع تست می‌باشد. البته منظور از تست، تست تیمی و تست خود نرم افزار می‌باشد. نرم افزار‌های آلفا هنوز ممکن است خطا و اشکالاتی داشته باشند و ممکن است اطلاعات شما از بین رود. در این مرحله امکانات جدیدی مرتبا به نرم افزار اضافه می‌گردد.
3. Beta
   نرم افزار بتا، همه قابلیت‌های آن تکمیل شده و خطا‌های زیادی برای کامل شدن نرم افزار وجود دارد. در این مرحله بیشتر به تست کاهش تاثیرات به کاربران و تست کارایی دقت می‌شود. نسخه بتا، اولین نسخه‌ای خواهد بود که بیرون شرکت و یا سازمان در دسترس قرار می‌گیرد. برخی توسعه دهندگان به این مرحله preview، technical preview یا early access نیز می‌گویند.
4. Release candidate
   در این مرحله نرم افزار، آماده عرضه به مصرف کنندگان است و نرم افزارهایی مثل سیستم عامل‌های ویندوز در دسترس تولید کنندگان قرار گرفته تا با جدید‌ترین سخت افزار خود یکپارچه شوند.

• General availability (GA)
  در این مرحله، عرضه عمومی نرم افزار و بازاریابی و فروش نرم افزار مد نظر است و علاوه بر این تست امنیتی و در نرم افزار‌های خیلی بزرگ عرضه جهانی صورت می‌گیرد

چرا نرم افزار خود را نسخه‌بندی کنیم و نسخه‌بندی معنایی(Semver) چیست !؟

در دنیای مدیریت نرم‌افزار یک موقعیت ناخوشایند به نام "جهنم وابستگی" وجود دارد. هر چه سیستم شما بزرگ‌تر می‌شود و هر چه کتابخانه‌های بیشتری به نرم‌افزار خود می‌افزایید، به همان میزان احتمال گرفتار شدن شما در این دام بیشتر خواهد شد.

در سیستم‌هایی با وابستگی بسیار زیاد، انتشار نسخه جدید کم کم تبدیل به یک کابوس می‌شود. اگر وابستگی شما به کتابخانه‌ها بسیار زیاد و پیچیده باشد، شما در معرض خطر قفل شدن انتشار نسخه جدید قرار می‌گیرید (عدم توانایی برای بروزرسانی یک کتابخانه بدون انتشار نسخه جدید کتابخانه‌های وابسته). اگر وابستگی شما به کتابخانه‌ها خیلی بی‌قاعده و کم باشد، شما ناگزیر توسط نسخه‌های بی‌قاعده درگیر می‌شوید. هنگامی که مشکل قفل شدن انتشار نسخه جدید و/یا انتشار نسخه‌های بی‌قاعده شما را از حرکت مناسب و خوب برای تکمیل پروژه‌تان بازمی‌دارد، در واقع شما در "جهنم وابستگی" قرار دارید.

به عنوان یک راه حل برای حل این مشکل، یک مجموعه ی ساده از قوانین و الزامات که چگونگی طراحی شماره های نسخه و افزایش آن را دستور میدهد را پیشنهاد می‌کنیم. برای کار کردن این سیستم، شما ابتدا نیاز به اعلام API عمومی دارید. این خود ممکن است شامل مستندات و یا اجرای کد باشد. علی رغم آن، مهم است که این API روشن و دقیق باشد. هنگامی که API عمومی خود را تعیین کردید، تغییرات برنامه شما بر روی نسخه API عمومی تاثیر خواهد داشت و آنرا افزایش خواهد داد. بر این اساس، این مدل نسخه‌بندی را در نظر بگیرید: X.Y.Z یعنی (Major.Minor.Patch). رفع حفره‌هایی که بر روی API عمومی تاثیر نمی‌گذارند، مقدار Patch را افزایش می‌دهند، تغییرات جدیدی که سازگار با نسخه قبلی است، مقدار Minor را افزایش می‌دهند و تغییرات جدیدی که کاملا بدیع هستند و به نحوی با تغییرات قبلی سازگار نیستند مقدار Major را افزایش می‌دهند.

توضیح روش SemVer برای نسخه بندی نرم افزار

عددی که برای نسخه نرم افزار توسط روش 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

نسخه های بالا به ترتیب یعنی عرضه اولیه (آلفا ) که ۱۷ مرتبه اصلاح شده و نسخه پیش از انتشار رسمی که ۱۲ بار رفع خطا شده .

نکاتی که باید در نسخه بندی حتما رعایت شود :

• جدا کننده نسخه با کلمه پیش از انتشار حتما باید   –   باشد .
• نیازی نیست برای هر تغییر و رفع اشکالی نسخه جدید انتشار دهید . میتوانید برای رفع یکباره 5 ایراد ، یک عدد به Z اضافه کنید.
• اگر عدد  x  تغییر کند عدد y و عدد z صفر می شود .
• به عنوان مثال اگر نگارش فعلی ۴.۶.۱۴ باشد ( یعنی نسخه ۴ با ۶ تغییر و ۱۴ رفع ایراد ) ورژن بعدی ۵.۰.۰ خواهد بود ( ورژن ۵ که هنوز تغییر و رفع ایرادی نداشته )
• حتما باید نسخه کامل نوشته شود . ( نمی توانید نسخه ۵.۰.۰ را نسخه ۵ بنویسید)
• محلی در شروع برنامه یا در فرم اصلی برای مطلع کردن کاربر از نسخه نصب شده حتما قرار دهید.

منابع:آفیس‌باز - قلم مجتبی کاویانی