نسخه گذاری معنایی

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

معرفی:

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

نسخه‌گذاری

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

مشخصات نسخه گذاری معنایی SemVer

  1. نرم افزارهایی که از روش نسخه گذاری معنایی استفاده می کنند، لازم است API عمومی را تعریف کنند. این APIها می‌تواند در کد تعریف شده باشد و یا به صورت مشخصی در مستندات وجود داشته باشد. به هر شکلی انجام شود لازم است دقیق و جامع باشد.
  2. شماره نسخه معمول باید از ساختار X.Y.Z پیروی کند. که X و Y و Z اعداد صحیح هستند و شامل عدد صفر پیش از عدد غیر صفر در هر بخش ( مانند ۰۰۷ ) نمی‌باشد. X نسخه اصلی ، Y نسخه فرعی ، Z نسخه وصله هستند. هر بخش باید عددی افزایش یابد ( مانند ۱٫۹٫۰ – ۱٫۱۰٫۰ – ۱٫۱۱٫۰ )
  3. زمانی که یک بسته نسخه گذاری شده منتشر شد، محتوای آن نسخه نباید تغییر کند. هرگونه تغییری لازم است با یک نسخه جدید منتشر شود.
  4. شماره نسخه اصلی صفر ( ۰٫y.z ) برای ابتدای توسعه می باشد. هر چیزی و در هر زمانی می‌تواند تغییر کند. API عمومی به صورت پایدار در نظر گرفته نمی‌شوند.
  5. نسخه ۱٫۰٫۰ معرفی کننده API های عمومی است. روشی که شماره نسخه پس از این انتشار افزایش می‌یابد به API های عمومی موجود در این نگارش وابسته است.
  6. شماره نسخه وصله Z ( در نسخه پس از فاز ابتدایی توسعه ) باید زمانی افزایش یابد که رفع باگهایی که با API عمومی سازگار است ارایه شده باشد. رفع باگ به عنوان تغییری داخلی که رفتارهای نادرست را اصلاح می کند شناخته می شود.
  7. شماره نسخه فرعی Y زمانی باید افزایش یابد که کارکردها و قابلیت‌های سازگار با API عمومی ارایه شده باشد. نسخه فرعی زمانی که هرکدام از کارکردهای API عمومی از رده خارج می‌شود نیز باید افزایش یابد. این امکان نیز وجود دارد شماره نسخه فرعی در تغییرات و بهبود ها در سطح توابع داخلی رخ داد نیز افزایش یابد. شماره نسخه وصله ها باید صفر شوند اگر شماره نسخه فرعی افزایش یافت.
  8. نسخه اصلی X باید زمانی که تغییرات ناسازگار با API های عمومی انجام شد افزایش یابد. به عبارتی زمانی که API های عمومی افزایش یابند یا ساختار بیرونی API های تغییر کند لازم است شماره نسخه اصلی افزایش یابد. با افزایش شماره نسخه اصلی شماره نسخه فرعی و وصله صفر خواهند شد.
  9.  نسخه پیش از انتشار می تواند با افزودن یک خط فاصله و مجموعه از حروف و اعداد بدون فاصله بعد از آن به شماره اصلی نسخه شناسایی شود مانند ۱٫۰٫۰-alpha – ۱٫۰٫۰ – alpha.1 برچسب‌های مشخص کننده نسخه پیش از انتشار مشخص می‌کند نسخه هنوز پایدار نیست و ممکن است نیازمندیهای مورد انتظار مطابق آنچه برای نسخه عادی آن تدوین شده است را پوشش ندهد.
  10. ارجحیت شماره نسخه، نشان دهنده روش مقایسه نسخه های مختلف است. به عنوان مثال نسخه‌های زیر به این ترتیب شناسایی می شوند. ۱٫۰٫۰ < 2.0.0 < 2.1.0 < 2.1.1 < 2.2.0 و نسخه گذاری پیش از انتشار ارجحیت پایین‌تری نسبت به نسخه عادی دارد ۱٫۰٫۰alpha < 1.0.0

نسخه گذاری

چرا از نسخه گذاری معنایی استفاده کنیم؟

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

فرض کنید نرم‌افزاری با نام «کامیون آتش‌نشانی» داریم که به یک بسته نرم‌افزاری دیگر بنام «نردبام» که از روش نسخه‌گذاری معنایی استفاده کرده است نیازمند است. در زمانی که «کامیون آتش‌نشانی» ایجاد شده باشد نسخه ۳٫۱٫۰ از «نردبام» مورد استفاده بوده است. در فهرست وابستگی‌ها می‌توانیم ثبت کنیم که «کامیون آتش‌نشانی» با نسخه‌هایی از «نردبام» سازگار است که نسخه‌های آن بزرگتر یا مساوی ۳٫۱٫۰ و کمتر از ۴٫۰٫۰ باشد. و هر انتشاری از این بسته که شماره نسخه آن در این فهرست باشد می‌تواند بدون ایجاد مشکل در نرم افزار «کامیون آتش‌نشانی» مورد استفاده قرار گیرد.

ترجمه: مهندس علی‌دوست

منبع

2 دیدگاه در“نسخه گذاری معنایی

  • 1394-04-31 در13:52
    پیوند یکتا

    مطلب خوبی بود و از آن انشالله در نسخه‌گذاری گزارشات وب و پرتال پرسنلی استفاده خواهیم کرد. اما دو سوال، اگر یک تغییر هم شامل بهبود و هم رفع باگ باشد، شماره گذاری به چه صورت خواهد شد؟ در نرم‌افزارهای که شامل چند بستر می‌باشند (مثلا اندروید و iOS) نسخه‌گذاری روی نوع بستر هم لحاظ می‌گردد یا خیر؟
    با سپاس

    پاسخ
    • 1394-04-31 در17:29
      پیوند یکتا

      ممنون از توجه شما ،
      درباره اینکه اگر تغییری هم شامل بهبود و هم رفع باگ باشد ، به نظر ترتیب ارسال کد به سورس کنترلر یا ترتیب بیلد نسخه می تواند مشخص کننده نوع شماره گذاری باشد. و از آنجا که ارتقای نسخه در بخش وصله و بهبود داخلی عملکرد ، تاثیری بر وابستگی ندارد ( زیرا وابستگی خدشه دار نمی شود ) به هرشکل عمل شود مشکلی نخواهد داشت.
      در مورد نرم افزارهای قابل استفاده روی چند بستر اگر بیلد شدن برای هر بستر مجزا باشد، نسخه گذاری هم قاعدتا مجزاست زیرا ممکن است باگهایی بر حسب بستر وجود داشته باشد. ولی اگر بواسطه بستر دیگری ( مانند استفاده از جاوا ماشین ) روی چند بستر قابل استفاده است نیازی به جدا سازی نسخه گذاری نخواهد بود.
      و البته مساله مهم این است که به هرشکلی قرارداد شود که انجام شود در تمام طول توسعه باید به یک شکل رفتار شود مگر آنکه ذینفعان از تغییر در مدل نسخه گذاری مطلع شوند .
      با تشکر

      پاسخ

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *