Semantic Versioning:نسخه‎دهی مفهومی چیست و چرا به آن نیاز دارید ؟

بسیاری از نرم افزار هایی که عموما استفاده می کنید نسخه های جدید را بصورت مرتب ارائه می‎کنند ، از شماره نسخه ( ورژن یا ورزیون ) همبسته استفاده می‎کنند ، این سیستم به نام سمانتیک ورژنینگ شناخته می‎شود ، این سیستم به شما امکان ردگیری روند توسعه نرم افزار را می‎دهد ، مثلا اگر با وردپرس کار کرده باشید از یک نمونه خوب semantic versioning (سِمَنتیک یا سیمانتیک ) بهره برده و آن را تجربه کرده‎اید.

در دنیای مدیریت نرم‌افزار یک فلسفهٔ ترسناک وجود دارد به اسم «جهنم وابستگی‌ها». به عبارت دیگر، نرم‌افزار شما بزرگ‌تر شده و رشد می‌کند و پکیج‌های بسیاری به نرم‌افزار شما افزوده می‌شود (احتمالاً شما یک روز خود را در این گودال ناامیدی ببینید که به معنای واقعی کلمه دیگر دیر شده است).سیستمی که وابستگی‌های آن بسیار پیچیده است، انتشار پکیج‌های نسخه جدید در آن می‌تواند به یک کابوس تبدیل شود و در صورتی‌ که وابستگی‌های نرم‌افزار خیلی بالا باشد، نرم‌افزار با خطر قفل نسخه مواجه است (برای ارتقاء یک پکیج، نیاز به انتشار نسخه‌های جدید پکیج‌های وابسته است).جهنم وابستگی جایی است که در آن قفل نسخه (Version Lock) و یا بی‌قاعدگی نسخه (Version Promiscuity)، مانع پیشبرد پروژه‌ٔ به‌صورت ایمن و آسان می‌شود.

در این مقاله یک معرفی سریع بر Semantic Versioning داشته و خواهیم دید که این سیستم چگونه کار می‎کند ، بعد در خصوص اینکه چطور می‎توانیم از مزایای آن استفاده کنیم و همچنین چند نکته برای اینکه مطمئن شویم به درستی از آن استفاده می‎‎کنید ارائه خواهیم کرد، چون در زبان پارسی ورژنینگ به شماره نسخه و نسخه دهی شناخته می شود و سمانیتک هم به معنی معنایی و مفهومی است ما در این مقاله از عبارت “semantic versioning” یا نوشته پارسی آن “سمانیتک ورژنینگ” در بیشتر موارد استفاده می کنیم که حق مطلب به درستی بیان شود همچنین به در برخی عبارت ها هم برای مانوس شدن ذهن با معادل پارسی این عبارت از نسخه دهی مفهمومی یا شماره نسخه مفهومی یا نسخه دهی مفهومی استفاده شده.

خوب ، برویم تا با زبان اعداد مفهومی در نسخه‎دهی صحبت کنیم.

Semantic Versioning چیست ؟

Semantic Versioning مجموعه قوانین ساده‌ ارائه‌ شده ای است که تعیین می‌کند از کدام شماره‌ٔ نسخه استفاده شود. برای کار با این سیستم، ابتدا باید یک هسته نرم افزار یا API عمومی، واضح و دقیق داشته باشید. پس از مشخص کردن یک API عمومی، تغییرات لازم در آن با افزایش شمارهٔ نسخه، اعمال می‌شود. ب

این سیستم Semantic Versioning نام دارد. با این طرح، شمارهٔ نسخه‌ها و نحوه تغییر آن‌ها مفهوم کد مربوطه و تغییری که در نسخهٔ جدید حاصل‌ شده است را منتقل خواهند کرد.

اگر به سایت وردپرس و بخش دانلود آن مراجعه کنید ، متوجه خواهید شد که نسخه فعلی CMS که در حال دانلود آن هستید را به شما نمایش میدهد ، مانند تصویر زیز که در زمان جمع آوری مطلب 5.1.1 و در زمان نگارش صرفا 5.2 یا همان 5.2.0 است.

سیستمی که برای تعیین این اعداد استفاده می شود ورژنینگ یا نسخه دادن نامیده می شود ، بصورت دقیقتر چیزی که در بالا اشاره شده یک نمونه از نسخه  دادن مفهومی یا Semantic Versioning است که شماره توزیع به سه عدد مجزا که با نقطه از هم جدا شده اند تقشیم می ‎شود. خوب با هم مروری روی اینکه هر کدام از این اعداد چه معنایی می‎دهند خواهیم داشت ، سه شماره نسخه Major.Minor.Patch

• نسخه Major یا بزرگ که به همراه تغییرات ساختاری در API و زیرساخت برنامه ارائه می شود و معمولا تغییرات در سطح ایجاد ناسازگاری با نسخه قبلی خواهد بود
• نسخه Minor که شامل بروزرسانی های نرم افزار بصورت اساسی و محسوس به شیوهٔ Backward Compatible اما نه به اندازه ای که یک نسخه Major حساب شده یا تاثیر عملکردی گسترده ایجاد کند
• نسخه Patch که معمولا باگ ها با روشی حل می شوند و به شیوهٔ Backward Compatible پیاده سازی شده باشد

در زمان آماده سازی این مطلب نسخه 5.1.1 برای وردپرس ارائه شده و در 6 دسامبر 2018 نسخه 5.0.0 به عنوان اصلی ترین نسخه 5 عرضه شده بوده ، از زمان عرضه نسخه اصلی 5 تغییراتی در شماره نسخه های وردپرس با رفع برخی مشکلات بوسیله وصله ها (Patch)  انجام شده

• 5.0.1
• 5.0.2
• 5.0.3
• 5.0.4
• 5.1
• 5.1.1

همانطور که مشاهده می کنید شماره بخش آخر که Patch می باشد هر بار که یک آپدیت از نوع Minor انجام شده ریست شده است ، همین موضوع در خصوص نسخه Major هم صحت دارد که بصورت سنتی هر 4 ماه یکبار در وردپرس انجام می شود.

تمام مقصود پشت شماره‎گزاری مفهومی با Semantic Versioning این است که به شما امکان ردگیری تمام تغییرات و پیشرفت هایی که انجام می‎دهید را بدهد، فراتر از آن اگر یک کاربر نهایی نرم افزار هستید در جریان نسخه های منتشر شده ( ریلیز ) قرار بگیرید و بدانید چه زمانی واقعا مهم است که سیستم خود را آپدیت کنید ، به عنوان مثال ممکن است بخواهید یک یا دو نسخه مربوط به رفع باگ ها و وصله ها را نادیده بگیرید اما وقتی یک نسخه Minor ارائه میشود به خودتان قول داده باشید که برنامه و وقت برای  آپدیت داشت باشید ( حواسمون هست، زیر قول خودتون نزنید ، آپدیت ها واقعا مهم هستند !)

اگر واقعا مطمئن نیستید که آن نسخه ارائه شده ارزش آپدیت را دارد یا خیر معمولا باید گزارش تغییرات یا ChangeLog را مشاهده کنید که باز هم معمولا ! به ازای هر نسخه منتظر شده از نرم افزار ممکن است در دسترس عموم قرار بگیرد ، معمولا هر برنامه نویس و توسعه دهنده نرم افزار ارزش اقداماتی که انجام داده را با گذاشتن یک گزارش تغییرات مکتوب حفظ می‎کند.

کلا ، Semantic Versioning واقعا سرراست و خوش دست است ، حتی در شرایطی فراتر از توسعه نرم افزا و کدنویسی می‎توانید از آن استفاده کنید ، در ادامه خواهیم گفت که آن شرایط چه خواهد بود

چه کسی می‎تواند از مزایای بکارگیری Semantic Versioning استفاده کند ؟

عموما، فقط توسعه‎دهندگان نرم افزار اصلی را پیدا خواهید کرد که از سیستم ورژنینگ استفاده می‎کنند ، مثالهای بدیهی این مورد بروزرسانی خود هسته نرم افزار است ، البته توسعه دهندگان قالب و پلاگین ها هم میتوانند از سیستم سمانتیک ورژنینگ استفاده کنند ، اگر چه پیداکردن این اعداد در قالب ها و پلاگین ها قدری مشکل است ، به عنوان مثال اگر بخش پلاگین های سایت وردپرس را بررسی کنید اطلاعات نسخه ارائه شده و تغییرات آن را در سرفصل Development پیدا خواهید کرد ،

به همین شکل اطلاعات در خصوص توسعه قالب ها هم در صفحه مربوطه در سایت WordPress.org وجود دارد ، اگر چه در این مورد باید روی لینک Development Log که در پائین صفحه قرار داد کلیک کنید تا گزارش تغییرات را مشاهده کنید.

کوتاه اینکه ، تقریبا برای هر نوع پروژه ای که درگیر کد نویسی باشد میتوانید از سمانتیگ ورژنینگ استفاده کنید ، با اینحال کاربری هایی خارج از محیط های 100% توسعه ای و کد نویسی هم دارد ، مثلا میتوانید از ورژنینگ برای پروژه های طراحی یا رابط کاری و تجربه کاربری استفاده کنید و بوسیله آن تست های A/B را نیز راحتر طراحی و در صورت نیاز به نسخه قبلی برگردید ، در این مثال تغییرات که  ظاهری را با افزایش نسخه اصلی (Major) و افزودن و ویرایش المان ها و بهینه سازی های کوچک را با نسخه Minor و برای بخش آخر که Patch باشد را برای اصلاحات و برزورسانی های بصری ریز افزایش دهید.

گرچه سمانتیک ورژنینگ محبوب ترین زمانه است ، اما تنها سیستمی که میتوانید استفاده کنید نیست ، به عنوان مثال مرورگر کروم از سیستم نسخه دهی 4 بخشی استفاده می کند major.minor.build.patch

در پروژه های دیگر مانند اوبونتو از سیستم هایی مبتنی بر تاریخ نیز استفاده می شود ، مثلا در Ubuntu نسخه فعلی 19.04 است که همانطور احتمالا حدس زده اید مربوط به نسخه منتشر شده در آوریل 2019 است ،

در کل ، فقط یک سیستم نسخه دهی که برای همه نیازها پاسخ گو باشد وجود ندارد ، اما سمانتیک ورژنینگ گزینه خوبی برای استفاده از انواع پروژهای توسعه نرم افزار است ، بعلاوه اینکه شروع خوبی برای آنهایی است که از هیچ پروتوکل نسخه دهی استفاده نمی‎کنند.

3 مورد از بهترین روشهای استفاده از Semantic Versioning

این جا یک ایده کلی از اینکه سمانتیک ورژنینگ چطور کار می کند دارید ، اما به برخی نکات برای اینکه مطمئن شویم می‎توانید بلافاصله و درستی از این سیستم استفاده خواهید کنید اشاره می‎کنیم.

بلافاصله از نسخه 1.0 شروع نکنید !

احتمالا تا به حال از نرم افزاری استفاده کرده اید که هنور به نسخه 1.0 نرسیده است ، این یک امر کاملا طبیعی است ، چون که کاربران انتظار دارند نسخه 1.0.0 یک نسخه منتظر شده پایدار و بدون باگ باشد. اگر چه این کار ممکن است  به شرایطی منتهی می شود که نرم افزار با اینکه برای مدت زمان زیادی کاملا استفاده است اما هنوز به نسخه 1 نرسیده است، این موضوع در بحث MVP در استارت‎آپ ها می‎تواند اهمیت داشته باشد و باید همیشه باد دقت مورد تحلیل قرار گیرد .

مثلا بازی محبوب Dwarf Fortress را به عنوان مثال در نظر بگیرید ، این بازی حدود 15 سال است که در حال توسعه است ! ولی هنوز در نسخه 0.44.12 است ، در صورتی که قابلیهای بیشتر از خیلی از بازی های اصلی در این سبک دارد !

با اینکه می‎توانید در این وارد مواضع افراط و تفریط شوید ، شروع نکردن با نسخه 1.0.0 بلافاصله با شروع یک پروژه نرم افزاری منطقی است و برای شما امکان تست بتای نرم افزار و گرفتن بازخورد و انتظارت کاربران را در مراحل پیشبرد پروژه خواهد داد

برای شروع میتوانید از نسه 0.1.0 آغاز کنید ، اگرچه خیلی از پروژه ها این نسخه را بصورت عمومی منتشر نخواهند کرد و منتظر توسعه بیشتر آن پروژه می‎مانند ، در همین حین می‎توانید از نسخه alpha برای تست های داخلی استفاده کنید که کلید توسعه و سلامتی هر پروژه نرم افزاری است .

 تغییرات مشخص برای هر نسخه را شرح دهید

یکی از شرایط آزاد دهنده برای شما به عنوان کاربر نهایی محصول نرم افزاری این خواهد بود که تعداد زیادی آپدیت را بدون اینکه بدانید آن آپدیت ها قرار است چه کاری انجام دهند دریافت کنید ، مامی‎دانیم خیلی از مردم فایل Changelog را نخواهند خواند ، اما اگر یک آپدیت ( حتی یک وصله کوچک ) را قرار می‎دهید لازم است تا آن را مستند کنید

گزارش تغییرات یا Changelog همانطورکه نامش گویای آن است ، نشانگر ساده این است که هر نسخه منتشر شده چه چیزی جدید است و چه تغییراتی انجام شده ، برخی از توسعه دهندگان متون طولانی و تشریحی برای تک تک تغییراتی که انجام داده اند نگارش می‎کنند ، اگر شما یکی از آنها هستید ، خدا قوت !

اما اگر بخواهیم صادق باشیم ، ما محتوایی از چیزهای جدید را بصورت لیستی ساده ارائه می‎کنیم ، گردآوری گزارش تغییرات ساده است و نباید زمان زیادی نیاز داشته باشد پس لطفا از زیر بار وظیفه توسعه دهنده بودن شانه خالی نکنید 😎 

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

احتمالا دهنیتی کامل و دقیق از اینکه  پروژه نهایی باید به چه شکل باشد دارید ، اما این به این معنی نیست که می‎توانید از بازخورد کاربران و باقی تیم چشم‎پوشی کنید.

ایده آل این است که : چند مرحله بازخورد را در هر نسخه ای که منتشر می‎کنید دریافت کنید (‌غیر از  وصله‎ها و رفع باگ‎های کوچک و مشخص ). هدف از این کار اینجا این است که متوجه بشوید آیا کاربران با مشکلی مواجه شده  یا مشکلاتی دارند که با مسیری که پروژه به آن سمت می‎رود همخوانی ندارد؟

ساده ترین مثالی که از این عملکرد می توان  داشت است که آخرین نسخه یک سایت در دست طراحی را با مشتری به اشتراک بگزارید ، در غالب موارد کاربر سطوحی از بازخورد را برای شما خواهد داشت که می‎توانید آنها را در نسخه های منتشر شده بعدی در نظر بگیرید .

با اینحال توجه کنید که گوش دادن به بازخورد (Feedback ) مهم است اما در برخی موارد ممکن است بهتر از کاربر خود نیاز را درک کنید و یا شما در مسیر پروژه دچار اسکوپ کریپ شوید ، اما این به معنی نیست که باید بازخورد آنها را نادیده بگیرید ولی بری اوقات ممکن است حس شما درست باشد!

کنترل جمع بندی

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

یک جمع بندی از بهترین روشهایی که بیاد همیشه در سمانتیک ورژنینگ در ذهن خود داشته باشید :

• اولین نسخه را با 1.0.0 شروع نکنید.
• همه تغییرات سک نسخه جدید را شرح بدهید
• فیدبک کاربران از هر نسخه منتشر شده را دریافت کنید.

سوالی در خصوص نسخه دهی نرم افزار دارید ؟ نقطه نظر و یا انتقادی به این مقاله دارید ؟ آنها را در فرم نظرات پائین همین صفحه درج کنید.

کپی رایت تصاویر مقاله برای fatmawati achmad zaenuri / shutterstock.com