آموزش متد نسخه بندی نرم افزار ها

قطعا نرم افزارهای زیادی را دیده اید که نسخه آنها با چهار عدد که به واسطه . از هم جدا شده اند ورژن بندی شده اند مانند آفیس ۲۰۱۳ با ورژن ۱۵٫۰٫۴۴۸۱٫۱۵۰۸ یا سایر نرم افزار ها. در این پست با نحوه نسخه بندی نرم افزار ها آشنا خواهیم شد.

نسخه بندی نرم افزار یا Software versioning : برنامه‌های ویندوز هنگام برنامه نویسی با نرم افزار مربوطه خود (برای مثال ویژوال استودیو) یک فایل AssemblyInfo دارند که در قسمت آخر آن، اطلاعات مربوط به نسخه نرم افزار ذخیره می‌شود. هر نسخه نرم افزار شامل چهار بخش عددی می‌باشد که با نقطه از هم جدا شده است.

بخش عددی اول: Major Version یا عدد بزرگ => وقتی افزایش می‌یابد که تغییرات قابل توجهی در نرم افزار ایجاد شود
بخش عددی دوم: Minor Version یا عدد کوچک => وقتی افزایش یابد که ویژگی جزئی یا اصلاحات قابل توجهی به نرم افزار ایجاد شود.
بخش عددی سوم: Build Number یا شماره ساخت => به ازای هر بار ساخته شدن پروژه افزایش می‌یابد.
بخش عددی چهارم: Revision یا رقم تجدید نظر => وقتی افزایش می‌یابد که نواقص و باگ‌های کوچکی رفع شوند.

وقتی major یا minor افزایش یابد می‌تواند با کلماتی همچون alpha، beta یا release candidate همراه شود. در اکثر برنامه‌های تجاری اولین شماره انتشار یک محصول از شماره یک شروع می‌شود. ترتیب نسخه بندی هم ممکن است به یکی از دوشکل زیر تغییر یابد:

major.minor[.build[.reversion]]
major.minor[.maintenance[.build]]

انواع نسخه بندی ها

نسخه بندی مایکروسافت: اگر به نسخه برنامه Office توجه کرده باشید مثلا Office 2013 نسخه ۱۵٫۰٫۴۴۸۱٫۱۵۰۸ می‌باشد که در این روش از تاریخ شروع پروژه و تعداد ماه‌ها یا روز‌ها و یا ثانیه‌ها با یک الگوریتم خاص برای تولید نسخه نرم افزار استفاده می‌شود.

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

رفع حفره‌هایی که بر روی API عمومی تاثیر نمی‌گذارند، مقدار Patch را افزایش می‌دهند، تغییرات جدیدی که سازگار با نسخه قبلی است، مقدار Minor را افزایش می‌دهند و تغییرات جدیدی که کاملا بدیع هستند و به نحوی با تغییرات قبلی سازگار نیستند مقدار Major را افزایش می‌دهند.

۱- نرم‌افزارهایی که از نسخه بندی معنایی استفاده می‌کنند، باید یک API عمومی داشته باشند. این API می‌تواند در خود کد یا و یا به طور صریح در مستندات باشد که باید دقیق و جامع باشد.

۲- یک شماره نسخه صحیح باید به شکل X.Y.Z باشد که در آن X،Y و Z اعداد صحیح غیر منفی هستند. X نسخه‌ی Major می‌باشد، Y نسخه‌ی Minor و Z نسخه‌ی Patch می‌باشد. هر عنصر باید یک به یک و بصورت عددی افزایش پیدا کند. به عنوان مثال: ۱٫۹٫۰ -> 1.10.0 -> 1.11.0

3- هنگامی که به یک نسخه‌ی Major یک واحد اضافه می‌شود، نسخه‌ی Minor و Patch باید به حالت ۰ (صفر) تنظیم مجدد گردد. هنگامی که به شماره نسخه‌ی Minor یک واحد اضافه می‌شود، نسخه‌ی Patch باید به حالت ۰ (صفر) تنظیم مجدد شود. به عنوان مثال: ۱٫۱٫۳ -> 2.0.0 و ۲٫۱٫۷ -> 2.2.0

4- هنگامیکه یک نسخه از یک کتابخانه منتشر می‌شود، محتوای کتابخانه مورد نظر نباید به هیچ وجه تغییری داشته باشد. هر گونه تغییر جدیدی باید در قالب یک نسخه جدید انتشار پیدا کند.

۵- نسخه‌ی Major صفر (۰٫Y.Z) برای توسعه‌ی اولیه است. هر چیزی ممکن است در هر زمان تغییر یابد. API عمومی را نباید پایدار در نظر گرفت.

۶- نسخه ۱٫۰٫۰ در حقیقت API عمومی را تعریف می‌کند. چگونگی تغییر و افزایش هر یک از نسخه‌ها بعد از انتشار این نسخه، وابسته به API عمومی و تغییرات آن می‌باشد.

۷- نسخه Patch یا (x.y.Z | x > 0) فقط در صورتی باید افزایش پیدا کند که تغییرات ایجاد شده در حد برطرف کردن حفره‌های نرم‌افزار باشد. برطرف کردن حفره‌های نرم‌افزار شامل اصلاح رفتارهای اشتباه در نرم‌افزار می‌باشد.

۸- نسخه Minor یا (x.Y.z | x > 0) فقط در صورتی افزایش پیدا خواهد کرد که تغییرات جدید و سازگار با نسخه قبلی ایجاد شود. همچنین این نسخه باید افزایش پیدا کند اگر بخشی از فعالیت‌ها و یا رفتارهای قبلی نرم‌افزار به عنوان فعالیت منقرض شده اعلام شود. همچنین این نسخه می‌تواند افزایش پیدا کند اگر تغییرات مهم و حیاتی از طریق کد خصوصی ایجاد و اعمال گردد. تغییرات این نسخه می‌تواند شامل تغییرات نسخه Patch هم باشد. توجه به این نکته ضروری است که در صورت افزایش نسخه Minor، نسخه Patch باید به ۰ (صفر) تغییر پیدا کند.

۹- نسخه Major یا (X.y.z | X > 0) در صورتی افزایش پیدا خواهد کرد که تغییرات جدید و ناهمخوان با نسخه فعلی در نرم‌افزار اعمال شود. تغییرات در این نسخه می‌تواند شامل تغییراتی در سطح نسخه Minor و Patch نیز باشد. باید به این نکته توجه شود که در صورت افزایش نسخه Major، نسخه‌های Minor و Patch باید به ۰ (صفر) تغییر پیدا کنند.

۱۰- یک نسخه قبل از انتشار می‌تواند توسط یک خط تیره (dash)، بعد از نسخه Patch (یعنی در انتهای نسخه) که انواع با نقطه (dot) از هم جدا می‌شوند، نشان داده شود. نشان‌گر نسخه قبل از انتشار باید شامل حروف، اعداد و خط تیره باشد [۰-۹A-Za-z-]. باید به این نکته دفت داشت که نسخه‌های قبل از انتشار خود به تنهایی یک انتشار به حساب می‌آیند اما اولویت و اهمیت نسخه‌های عادی را ندارد. برای مثال: ۱٫۰٫۰-alpha ، ۱٫۰٫۰-alpha.1 ، ۱٫۰٫۰-۰٫۳٫۷ ، ۱٫۰٫۰-x.7.z.92

11- یک نسخه Build می‌تواند توسط یک علامت مثبت (+)، بعد از نسخه Patch یا نسخه قبل از انتشار (یعنی در انتهای نسخه) که انواع آن با نقطه (dot) از هم جدا می‌شوند، نشان داده شود. نشان‌گر نسخه Build باید شامل حروف، اعداد و خط تیره باشد [۰-۹A-Za-z-]. باید به این نکته دقت داشت که نسخه‌های Build خود به تنهایی یک انتشار به حساب می‌آیند و اولویت و اهمیت بیشتری نسبت به نسخه‌های عادی دارند. برای مثال: ۱٫۰٫۰+build.1 ، ۱٫۳٫۷+build.11.e0f985a

12- اولویت‌بندی نسخه‌ها باید توسط جداسازی بخش‌های مختلف یک نسخه به اجزای تشکیل دهنده آن یعنی Minor، Major، Patch، نسخه قبل از انتشار و نسخه Build و ترتیب اولویت بندی آن‌ها صورت گیرد. نسخه‌های Minor، Major و Patch باید بصورت عددی مقایسه شوند. مقایسه نسخه‌های قبل از انتشار و نسخه Build باید توسط بخش‌های مختلف که توسط جداکننده‌ها (نقطه‌های جداکننده) تفکیک شده است، به این شکل سنجیده شود:

بخش‌هایی که فقط حاوی عدد هستند، بصورت عددی مقایسه می‌شوند و بخش‌هایی که حاری حروف و یا خط تیره هستند بصورت الفبایی مقایسه خواهند شد.