نسخه بندی یک نرم افزار (از هر نوع) بخشی از یک پروژه است و این مورد زمانی که نیاز به نرم افزاری هست که در طول زمان گسترش میابد، بسیار اهمیت پیدا می کند.
روش ها و متدهای مختلفی برای نسخه گذاری نرم افزارها ارائه شده است. در این بین روش Semantic Versioning که با نام اختصاری SemVer شناخته می شود در اکثر پروژه ها استفاده می شود (بطور مثال بیش از 90 درصد پروژه های موجود در گیت هاب از این روش برای نسخه بندی استفاده می کنند).
ساختار SemVer به چه شکل است؟
SemVer شامل سه عدد به شکل x.y.z می باشد:
- عدد
xبه معنای تغییرات گسترده در نرم افزار - عدد
yبه معنای تغییرات کوچک در نرم افزار - عدد
zبه معنای رفع اشکالات نرم افزار
در حقیقت نسخه نرم افزار به شکل Major.Minor.Patch می باشد.
نحوه کار SemVer به چه شکل است؟
بسیار ساده! بالا بردن عدد در بخش و زمان صحیح.
اگر اشکالاتی را در پروژه رفع کرده اید باید مقدار z را اضافه کنید.
اگر قابلیتی به پروژه اضافه کرده اید که با نسخه های قبلی سازگار است باید مقدار y را اضافه کنید (بدین معنی که بدون مشکلی می توان به نسخه جدید ارتقا داد).
و در آخر اگر پروژه شما دارای تغییراتی گسترده است که ممکن است برخی API های موجود را پشتیبانی نکند و نیاز به صرف زمان و دقت بیشتری برای ارتقا هست، باید مقدار x را افزایش دهید.
چرا باید از این شیوه عدد گذاری استفاده کنیم؟
بدین دلیل که ساده و مشخص است و می توان به آن استناد کرد. بطور مثال بعد از تغییرات نسخه باید 4.2 باشد؟ یا 5؟ یا 4.1.1 ؟ و…
دلیل بعدی واضح بودن نسخه برای دیگران است. برای مثال با دیدن نسخه 1.3.37 از یک پروژه می توان دریافت که بعد از ارائه نسخه 1، سه نسخه برای افزودن قابلیت های جدید ارائه شده و در نسخه کنونی 37 نسخه برای رفع ایرادات ارائه شده است.
دلیل مهم دیگر مدیریت وابستگی است. فرض کنید پروژه ای دارید با نام felan که برای اجرا نیازمند پروژه ای دیگر به نام bahman است. پروژه bahman در حال حاضر نسخه 2.3.7 را دارد. حالا شما می توانید با خیال راحت در صورت ارتقا bahman آن را تا قبل از نسخه 3.0.0 ارتقا دهید و از امکانات و رفع اشکالات آینده آن استفاده نمائید.
نکاتی که باید توجه داشته باشید
در زیر نکاتی را مشاهده می کنید که باید در هنگام نسخه بندی پروژه در نظر داشته باشید:
شروع از نسخه 0.1.0
شروع پروژه از نسخه 0.1.0 است نه 0.0.1
قبل از ارائه نسخه 1.0.0 تنها برای زمان توسعه
چه زمانی نسخه 1.0.0 ارائه می شود؟ زمانی که پروژه شما برای استفاده توسط کاربر و مشتری آماده شده است. در حقیقت از نسخه 1.0.0 نرم افزار شما باید پایدار باشد.
نسخه های پیش از انتشار
در فرآیند توسعه زمان هایی هست که می خواهید قبل از ارائه آن به کاربر و مشتری توسط عده ای تست و ایرادیابی شود. برای این کار می توانید از نسخه های پیش از انتشار استفاده کنید.
خود مراحل پیش از انتشار شامل سه نوع هستند که به ترتیب از پایین به بالا عبارتند از alpha ( آلفا )، beta ( بتا ) و rc ( کاندیدای انتشار ). این سه عبارت بعد از نسخه مورد نظر اضافه می شوند. بطور مثال اولین نسخه آلفای 1.0.0 یک پروژه می شود 1.0.0-alpha.1 و نسخه بعدی 1.0.0-alpha.2 نام می گیرد.
همانطور که در بالا عنوان شد ترتیب آن ها مهم است یعنی بتا بعد از آلفا و کاندیدای انتشار بعد از آن دو قرار می گیرد و این یعنی نسخه 1.0.0-beta.1 بالاتر و جدید از نسخه 1.0.0-alpha.8 است.
سوالات متداول
در زیر سوالاتی که ممکن از در هنگام نسخه گذاری پروژه با آن مواجه شوید عنوان شده است. اگر سوال دیگر دارید می توانید در بخش نظرات همین نوشته بپرسید.
آیا باید برای هر رفع اشکال ویا افزودن قابلیت جدید باید نسخه ای جدید ارائه کرد؟
بایدی وجود ندارد و البته بهتر است به این شکل صورت نگیرد. شما می توانید بعد از 10 رفع ایراد یک عدد به مقدار z اضافه کرده و نسخه جدیدی را منتشر کنید. زمان انتشار بسته به خودتان و شرایط پروژه دارد.
آیا باید بعد از رسیدن به عدد 9 یک نسخه به عدد بالاتر اضافه کرد؟
خیر. نسخه برنامه شما می توانید چیزی شبیه به 1.3.17 و یا 2.14.1 باشد.
آیا حتما برای جدا کردن اعداد از نقطه و پیش از شروع عبارت نسخه های پیش از انتشار از - استفاده کرد؟
بله. این روش استاندارد است و نحوه شماری گذاری نیز باید دقیقا به همین شکل باشد. این موضوع در برنامه های مدیریت وابستگی نظیر npm و bower بسیار اهمیت پیدا می کند و پیروی نکردن از آن باعث بروز مشکلات زیادی خواهد شد.
آیا نسخه برنامه باید حتما شامل 3 عدد باشد؟ بطور مثال برنامه من که در نسخه 1.1.0 است می تواند مختصرا با عبارت 1.1 شناخته شود؟
بله. عبارت باید حتما دارای 3 عدد باشد. شما در گفتگوهایتان می توانید از نسخه اختصاری گفته شده استفاده کنید!
نسخه پروژه من در حال حاضر 1.2.1 است و من تعدادی از ایرادات را برطرف و قابلیت هایی به آن اضافه کرده ام. نسخه بعدی من باید چه باشد؟
نسخه بعدی شما می شود 1.3.0
سخن آخر
اگر شما تاکنون از روش استانداردی برای نسخه گذاری پروژه خود استفاده نکردید بهتر است استفاده از آن را شروع کنید و آن را برای دیگر افراد تیمتان توضیح دهید.