نسخه بندی معنایی یا Semantic Versioning ، یکی از روش های معروف و پرکاربرد نسخه بندی نرم افزاره!
تو این روش به راحتی مشخص میکنیم نسخه ای که از یه نرم افزار، وبسایت، کتابخونه یا پکیج (یا بصورت کلی، هر محصولی که تو حوزه تکنولوژی تولید و توسعه داده میشه) ارائه میشه، دقیقا چه نوع تغییراتی توش به وجود اومده تا کاربر بتونه با نگاه اول تشخیص بده که نسخه جدید این نرم افزار یا وب سایت، تغییراتش تو چه قسمتاییش به وجود اومده!
همنطوری که تو عکس بالا میبینید، این روش نسخه بندی عموما از 3 قسمت کلی تشکیل شده : X . Y . Z
یه سری چیز میز دیگه هم داره که بهش اضافه میکنن که بعدا میگم بهتون! ?
قسمت اولش، همون X، تغییرات عمده و بزرگ (Major) بهش میگن و یه اسم دیگش هم هس: Breaking
این قسمت، هر موقع عددش عوض میشه، یعنی با نسخه کاملا جدید از محصول روبرو هستیم که تغییراتش پایه ای و خیلی عمده هس!
یا یکم به زبون علمی تر، به احتمال قوی، API هاش با نسخه قبلی سازگاری ندارن! ?
توی نرم افزار ها و وب سایت ها شاید اونقدرا برامون تأثیر گذار نباشه، ولی وقتی داریم از یه کتابخونه یا پکیج خاصی استفاده میکنیم، این قضیه برامون حیاتی تره!
چرا؟! چون اگر اون پکیج یا کتابخونه رو به این نسخه جدید آپدیت کنیم، امکان داره یه سری API ها و یا توابعی که توی نسخه قبلی بودن، تو نسخه جدید نباشن و این وسط کارمون خراب شه و مجبور شیم دوباره ازنو بازنویسی و توسعه داشته باشیم! (که این یعنی دردسر ?)
این قسمت دیر به دیر افزایش پیدا میکنه تقریبا! چون بالاخره شامل تغییراتیه که خیلی کلی و پایه ایه!
قسمت دومش، همون Y، تغییرات جزئی و کوچیک (Minor) بهش میگن و یه اسم دیگش هم هس: Feature
این قسمت، هر موقع عددش عوض میشه، یعنی یه سری قابلیت جدید به محصول اضافه شده! تغییرات به احتمال قوی، کلی و پایه ای نیستن و API ها با نسخه قبلی سازگاری دارن!
پس در نتیجه میتونیم با خیال راحت، اگه دلمون خواست محصولی که ازش استفاده میکنیم رو، به این نسخه آپدیت کنیم تا ویژگی های جدید رو داشته باشیم و بتونیم اگه خواستیم ازشون استفاده کنیم! ?
قسمت سومش ، همون Z، مربوط به رفع عیب ها و باگ ها، توی نسخه فعلی از محصول هس (Patch) و یه اسم دیگش هم هس: Fix
این قسمت، هر موقع عددش عوض میشه، قابلیت جدیدی به محصول اضافه نمیشه! بلکه همین قابلیت هایی که توی همین نسخه از محصول هس رو بهبود میدن و یا خطاهایی که پیدا کردن یا بهشون گزارش داده شده رو رفع میکنن و طبیعتا API ها با نسخه قبلی سازگاری دارن!
پس میتونیم با خیال خیلی راحت، اگه دلمون خواست که نه، بهتره حتما محصولی که ازش استفاده میکنیم رو به این نسخه آپدیت کنیم، تا جلوگیری کنیم از به وجود اومدن اشکالاتی که شاید تو آینده قراره از طرف خطاهای خود محصول، برامون دردسر درست کنن! ?
توی عکس بالایی هم میتونید یه مثال از این نوع نسخه بندی رو ببینید!
یادتونه گفتم بعضی اوقات میان یه سری چیز میز هم به این اعداد اضافه میکنن؟! ?
این مورد ها کاملا اختیاری هستن و برای دادن اطلاعات بیشتر ازشون استفاده میشه!
مثلا تو این عکس یکیشو نشون داده!
بهش میگن برچسب پیش انتشار! ?
(البته فک نکنم بهش اینو بگن! خودم تحت الفظی ترجمه کردمش! ?)
که بالافاصله بعد از قسمت اصلی نسخه بندی میاد و قبلش یه خط فاصله میزاریم که مشخصش کنیم!
عموما از سه تا اسم برا مشخص کردنش استفاده میشه: rc - beta - alfa
اغلب وقتی از این تگ ها استفاده میکنن که بخوان نسخه ای ارائه بدن که قراره X رو تغییر بده. یعنی شامل تغییرات Major باشه! قبل از انتشار این نسخه ها و توی زمانی که دارن تست های نهایی رو انجام میدن، این تگ ها رو به نسخه بندی اضافه میکنن. مثلا:
2.0.0-alfa.2
تگ alfa برای موقعی که داره تست های ابتدایی انجام میشه، استفاده میشه!
تگ beta برای موقع انجام تست هاییه که تمرکزش رو میزاره روی ویژگی های اصلی و مختلف تا باگ های احتمالی رو قبل از انتشار شناسایی کنه!
تگ rc هم بهش گفته میشه کاندید انتشار. از پس خیلی تست ها بر اومده و آماده معرفی به عنوان نسخه نهائیه!
یکی دیگه از اون چیز میزای اضافه، ابرداده (یا Metadata) هستش!
اینم دوباره برای دادن توضیحات بیشتر ازش استفاده میشه و کاملا اختیاره! و همین طور وقتی داریم از یه نسخه مشخص از محصولی استفاده میکنیم که توی نسخه بندیش ابرداده ذکر شده، نیازی نیست برای استفاده از اون نسخه، حتما ابرداده اونو هم مشخص کنیم!
یه نکته ریزی هم هس! اونم این که وقتی یه پروژه رو ای رو شروع میکنیم به توسعه دادن، اولین نسخه ای که بعد از توسعه اولین نیازمندی پروژه، باید بهش اختصاص داده بشه، 0.1.0 هستش!
تا اینکه محصولمون آماده بشه برای انتشار رسمی و نسخه ی 1.0.0 رو بهش اختصاص بدیم!
اگه تا الان از این روش نسخه بندی برای پروژه هاتون استفاده میکردین، که دمتون گرم! ?
ولی اگرم نه، که به نظرم خوبه یبار امتحانش کنید تو پروژتون! ?✌
خوبه واقعا! من که خودم باهاش حال کردم و خودمو موظف کردم حتما رعایتش کنم! کنترل و بررسی و نظارت رو توی روند جلو رفتن پروژه برام آسون تر و لذت بخش تر کرده!
و اینم بدونیم که اینکار، هرچقدرم درست و دقیق و به موقع انجام بشه، بدون مستندسازی درست و اصولی پروژه (Documentation) اونقدرا به درد نمیخوره ها! ?
باید بگیم که فلان باگ رفع شد! بگیم که این ویژگی جدید اضافه شد و اینجوری میشه ازش استفاده کرد! اگر هم که دیگه داریم یه نسخه کاملا جدید منتشر کنیم، دیگه حسابی دستمون بند میشه و باس کلی چیز بنویسیم براش!
همین چیزا که گفتمو توی این سایته میتونید کامل ترشو بخونید. البته زبونش خارجکیه و زحمت ترجمش با خودتون دیگه!
اینم یه سایته جالبه که برگه تقلبه نسخه بندی معناییه! (از سایت Devhints)
توی این سایت هم میتونید نسخه های مختلفی که برای یه کتابخونه و یا پکیج منتشر شده رو ببینید! مثال خوبیه برای اینکه روند کار این نوع نسخه بندی رو بهتر درک کرد! (از سایت NPM)
اینم پکیج رسمی ای که باهاش میتونید این رشته های نسخه بندی معنایی رو تجزیه (یا Parse) کنید و یا معتبر بودنشون رو بررسی کنید!
ممنون از وقتی که گذاشتید و خوندید! ?
امیدوارم تونسته باشم اطلاعات خوبی رو در اختیارتون گذاشته باشم و لذت برده باشید! ?✌
خوش ? باشید و سلامت ? و هر روز موفق تر از قبل ?
فعلا تا بعد ?
