یوشا آل ایوب

وبگاه دست نوشته ها و تجربیات شخصی
بِسمِ اللّه‏ِ الرَّحمنِ الرَّحيمِ

یوشا آل ایوب

وبگاه دست نوشته ها و تجربیات شخصی

یوشا آل ایوب

دکتر مصطفی چمران: می گویند تقوا از تخصص لازمتر است، آنرا می پذیرم، اما می گویم: آنکس که تخصص ندارد و کاری را می پذیرد، بی تقواست!

تبلیغات
Blog.ir بلاگ، رسانه متخصصین و اهل قلم، استفاده آسان از امکانات وبلاگ نویسی حرفه‌ای، در محیطی نوین، امن و پایدار bayanbox.ir صندوق بیان - تجربه‌ای متفاوت در نشر و نگهداری فایل‌ها، ۳ گیگا بایت فضای پیشرفته رایگان Bayan.ir - بیان، پیشرو در فناوری‌های فضای مجازی ایران
  • Version چیست

Version یا همون نسخه، مشخصه ای برای دسته بندی وضعیت محصول منتشر شده و [مختصر] شرحی از تغییرات انجام گرفته هستش.

به این معنی که Version یک محصول، بیانگر حال و روز کنونی و مقدار بهبود یافتگی اون محصول هستش... یا حتی آینده ای که در انتظارشه!

مشخصه Version می تونه بصورت عدد، کلمه و تاریخ باشه; یا حتی هر سه:

Major.Minor.Revision/Patch[.Build] [Architecture] ReleaseState [Date] [Time]

توجه: همونطور که می دونید استاندارد و تعریف رسمی برای مشخصه ها و اصطلاحات وجود نداره ولی در این مقاله سعی می کنم معمول ترین و کاملترین تعریف رو از قوائد Gnu، مستندات Eclipseسبک Semantic و غیره برای اینها انجام بدم...

 

مثال:

MyProgram 1.0.0 x86: یعنی این اولین انتشار MyProgram هستش و برای سخت افزارهای x86 طراحی شده.

 

MyProgram 1.7.5 w32 beta : یعنی این چندمین انتشار MyProgram هستش، اما public API برنامه ثابت مونده(1)، ظاهر و باطن برنامه کلی متحول شده(7) اما کماکان با نسخه های قبلی سازگاره، باگ های زیادی هم رفع شدن و بهبودهایی صورت گرفته(5)، برای سیستم عامل ویندوز نگارش 32 بیتی طراحی شده، این نسخه آزمایشیه(beta) و کمی باگ داره، احتمالاً حفره امنیتی نداره، اما 50% امکان داره تغییراتی درش صورت بگیره و مجدداً نسخه جدیدتری عرضه خواهد شد.

 

MyGitProject-v1.2.0-noarch-11-d8u3jd9k.zip: یعنی این آرشیو snapshot ای از MyGitProject هستش که از 0.branch 1.2 ساخته شده و وابسته به هیچ نوع(NoArch) معماری نرم/سخت افزاری نیست، همچنین حاوی 11 commit بعد از tag v1.2.0 هست و Git ref ش d8u3jd9k هستش.

 

MyLibrary 3.0.0.44 x64 A 2015/11/21 13:30: یعنی این چندمین انتشار MyLibrary هستش، تغییرات گسترده ای صورت گرفته و public API برنامه هم شکست داشته و با نسخه های قدیمیش سازگار نیست(3)، تا الان 44 بار build/compile شده، یرای سخت افزار های x64 طراحی شده، همچنین نسخه آزمایشی(Alpha) هه و باگ زیاد داره، حفره امنیتی داره، امکان از دست رفتن دیتای کاربر وجود داره و 75% امکان داره تغییرات خیلی بیشتری درش صورت بگیره یا حتی تغییرات قبلی rollback بشن، خیلی زود هم نسخه جدیدتری عرضه خواهد شد، در تاریخ 2015/11/21 در ساعت 13:30 منتشر شده.

 

Google Chrome 3160482924.76: ؟؟!!

 

Microsoft Office 2017: اینم فقط بیانگر نسخه جدید Microsoft Office هه و اومدنه سال نو و تبریکش...

اینگونه versioning بندی بسیار اشتباه و 100% marketing هستش. می بینید که هیچ گونه اطلاعاتی راجب نسخه منتشر شده وجود نداره، تا زمانی که اون محصول رو بخرید/دانلود کنید و بعد هم نصبش کنید! تازه می فهمید چی به چیه و چه اشتباهی کردید lol

 

در واقع Version یک محصول، شرح حال و چشم انداز اون محصول رو توضیح میده. با تفسیر درست Version میتونید اطلاعات کاملی راجب محصول بدست بیارید که بسیار در تصمیم گیری(برای استفاده یا جایگزینی) کمکتون می کنه.

 

  • اصول Versioning

برای Versioning درحال حاضر استاندارد رسمی وجود نداره اما اصول و قوائدی وجود دارن که با تبعیت از اونا میشه به نتیجه مطلوبی رسید. که من هم در این مقاله از اون قوائد(که شامل برخی مستندات RFC، قوائد Gnu، مستندات Eclipse, سبک Semantic و...) پیروی می کنم.

 

شمای معمول یک Version مناسب و کامل به این صورته:

Major.Minor.Revision/Patch[.Build] [Architecture] ReleaseState [Date] [Time]

توجه: واژه های داخل گیومه [] اختیاری هستند یا در بعضی از نرم افزار ها قادر به استفاده از اونها نیستید.

 

Major

مقدارش چیه؟ اعداد صحیح و برای انتشار عمومی از 1 شروع میشه.

چه زمانی عددشو تغییر بدیم؟

  • زمانی که شکست در public API نرم افزار صورت بگیره. (در حدی که کاربر نتونه نسخه جدید رو نسخه قدیم سازگار کنه (مثل library ها))
  • یا شیوه کار با نرم افزار تغییر کنه.
  • یا دگرگونی های اساسی و گسترده ای صورت بگیره.

چه تاثیری روی بقیه مشخصه ها میذاره؟ درصورت تغییر عدد Major، عدد Minor و عدد Revision/Patch مجدداً به 0 ریست می شن.

مثال: در نسخه 2.4.6 نرم افزار، یک شکست API صورت گرفت، پس نسخه جدید میشه 3.0.0.

 

نکته 1: اگر عدد Major تغییر کنه، دیگه نباید سعی کنید نرم افزار رو با نسخه های قبلیش سازگار کنید.

نکته 2: اگر نرم افزار در اولین فاز توسعه قرار داره و هنوز در دسترس عموم قرار نگرفته، در این صورت فقط عدد Minor و عدد Revision/Patch تغییر می کنن (مثل 0.1.0, 0.1.1, 0.2.3 و...) یا جدای از نسخه عمومی، یک نسخه داخلی هم برای نرم افزار درنظر گرفته میشه.

 

Minor

مقدارش چیه؟ اعداد صحیح و از 0 شروع میشه.

چه زمانی عددشو تغییر بدیم؟

  • زمانی که تغییرات جزئی در public API نرم افزار صورت بگیره. (در حدی که کاربر بتونه با تغییراتی در نرم افزار/دیتا خودش با نسخه جدید سازگار بشه)
  • یا ظاهر نرم افزار تغییر پیدا میکنه.
  • یا یک امکان جدید مهم اضافه میشه.
  • یا تعدادی امکانات جدید کوچیک اضافه میشه.
  • یا یک ماژول/کامپونت اضافه میشه.
  • یا performance به مقدار قابل توجهی افزایش پیدا میکنه.
  • یا روی بخش عمده ای از کد دوباره کار میشه.

چه تاثیری روی بقیه مشخصه ها میذاره؟ درصورت تغییر عدد Minor ، عدد Revision/Patch مجدداً به 0 ریست می شن.

مثال: در نسخه 2.4.6 نرم افزار، یک ماژول اضافه شده، performance هم افزایش پیدا کرده، پس نسخه جدید میشه 2.6.7.

 

Revision/Patch

مقدارش چیه؟ اعداد صحیح و از 0 شروع میشه.

چه زمانی عددشو تغییر بدیم؟

  • زمانی که تغییرات جزئی در کدها صورت بگیره.
  • یا باگی fix بشه.
  • یا مستندات نرم افزار تغییر پیدا کنن.
  • یا بهبود های جزیی صورت بگیره.
  • یا security patch انجام بگیره.
  • یا dependency ای update بشه. (با internal-library ها اشتباه نگیرید)

چه تاثیری روی بقیه مشخصه ها میذاره؟ اغلب هیچی

مثال: در نسخه 1.0.3 نرم افزار، مستندات نرم افزار بروز شدن، تعدادی از dependency ها بروز شدن، کمی بهبود در کدها صورت گرفت، پس نسخه جدید میشه 1.0.6.

 

Build

این مشخصه تعیین می کنه که نرم افزار چند بار compile/build شده. (یا در بعضی موارد فقط خطای داخلی رفع شده)

مقدارش چیه؟ اعداد صحیح و از 1 شروع میشه.

چه زمانی عددشو تغییر بدیم؟

  • در هربار که نسخه جدیدی compile یا build می کنین یک واحد عددشو بالا می برید.
  • یا خودش بصورت خودکار در هربار compile یک واحد افزایش پیدا می کنه.

چه تاثیری روی بقیه مشخصه ها میذاره؟ هیچی.

مثال: در نسخه 1.0.0.1 نرم افزار، یک ماژول اضافه شده، performance هم افزایش پیدا کرده، تعدادی امکانات جدید کوچیک اضافه شد، ظاهر نرم افزار تغییر کرد، مستندات نرم افزار بروز شدن، تعدادی از dependency ها بروز شدن، کمی بهبود در کدها صورت گرفت، پس نسخه جدید میشه 1.4.3.2.

 

Architecture

این مشخصه معمولاً کاربردش در نرم افزارهای باینری و تحت دسکتاپ(از هر نوعش) هستش. و مشخص می کنه که نرم افزار برای چه سیستم عامل یا سخت افزاری طراحی شده.

مقدارش چیه؟ x86, x64, i386, i486, ia64, arm64, w64, powerpc, sun3, w32 و...

چه تاثیری روی بقیه مشخصه ها میذاره؟ هیچی.

 

ReleaseState

این مشخصه از مرحله ای که کلنگ انجام پروژه زده میشه(intial) و تا مرحله ای که به نسخه Production برسه بصورت خودکار معلوم میشه. در واقع این مشخصه بیانگر کیفیت کنونی و چشم انداز نرم افزار هستش. کاربران هم از روی این مشخصه تصمیم میگیرن که از اون نرم افزار [در حال حاضر] استفاده کنند یا خیر.

مقدارش چیه؟ معمولاً Alpha, Beta, Closed beta, Open beta, RC, Development, Deprecated یا Stable هستند.

چه زمانی مقدارشو تغییر بدیم؟

این دیگه بستگی به شما، تصمیمتون برای ادامه کار، وضعیت کنونی نرم افزار، آینده نرم افزار و امثالش داره... ولی:

  • Deprecated: یعنی دیگه توسط سازندگانش پشتیبانی نمیشه، منسوخ شده و این نسخه رو نباید استفاده کرد.
  • Develop(یا گاهاً Pre-alpha): یعنی فعاله ولی در حال توسعه هستش، شاید برای پیش تولید alpha استفاده بشه، اما بیشتر برای اهداف آزمایشی و feature-testing توصیه میشه، در صورت تمایل دیگر توسعه دهندگان میتونن بهشون ملحق بشن.
  • Alpha: یعنی نسخه آزمایشی که سازندگانش بیشتر به کمیت و core نرم افزار توجه کردن، کیفیت و پرفورمنسش پایین هست، باگ و کرش زیاد داره، حفره های امنیتی وجود داره، احتمال از دست رفتن دیتای کاربر وجود داره، public API تغییر خواهد کرد، بیشتر ایده ها برای آزمایش اعمال شدند، ولی در آینده rollback و تغییرات زیادی درش صورت خواهد گرفت. (از alpha بیشتر برای جمع آوری گزارشات و بازخورد کاربران استفاده میشه)
  • Beta (یا گاهاً Betaware): یعنی نسخه آزمایشی که سازندگانش بیشتر به کیفیت و پرفرومنس نرم افزار توجه کردن، باگ و کرش کم داره، احتمالاً حفره امنیتی نداره، احتمال از دست رفتن دیتای کاربر کم هست، احتمالاً public API تغییر نخواهد کرد، اکثر ایده های اعمال شده تائید شدند، مسیر upgrade هموار شده، بعضی از ویژگی های نسخه Stable رو داراست، ولی در آینده تغییرات کمی درش صورت خواهد گرفت.
  • Closed beta: بعلاوه ویژگی های Beta، یعنی محدود شده و گروه خاصی می تونن ازش استفاده کنن. (حالا از طریق دعوت یا سطح دسترسی)
  • Open beta: بعلاوه ویژگی های Beta، یعنی برای تستر ها و گزارش دهندگان محدود شده، اما اگر دیگران هم در صورت تمایل میتونن بهشون ملحق بشن.
  • RC یا Release candidate یا Prepatch: یعنی کاندیدای انتشار، همه چیزش آماده و کاربردیست، عاری از باگ و کرشه، کاملاً ایمن هستش، public API ثابت مونده، قابلیت هاش تغییر نخواهند کرد، تمامی ویژگی های نسخه Stable رو داراست، همه feature ها تست شدند، شاید تغییرات بسیار جزیی درش صورت بگیره، بزودی هم Stable خواهد شد.
  • Stable: یعنی ماندگار و نهایی، نسخه ای که 100% production هست و آماده استفاده و عرضه بصورت گسترده! معمولاً زمانی رو هم برای End Of Life ش تعیین می کنن.

البته مشخصه های دیگه ای هم مثل TP, CTP, EOL, ESV, RTW, RTM, GA, Maintenance, Preview وجود دارن، ولی چون کم کاربرد هستند و کمتر کسی ازشون استفاده می کنه ما هم در اینجا کاری باهاشون نداریم...

چه تاثیری روی بقیه مشخصه ها میذاره؟ هیچی.

 

Date و Time

این مشخصه ها معمولاً برای marketing یا نرم افزارهای حساس(مثل بورس) استفاده میشه. اما پیشنهاد می کنم همیشه تاریخ انتشار رو در changelog ,news یا history محصولتون قرار بدید. (که کاربران بدونن مثلاً آخرین نسخه نرم افزار که 4.0.0 هست ماله 10 سال پیش بوده یا همین ماه های اخیر)

مقدارشون چیه؟ تاریخ و زمان

چه زمانی عددشو تغییر بدیم؟

  • هر زمان که نرم افزار رو منتشر/release می کنید.

چه تاثیری روی بقیه مشخصه ها میذاره؟ هیچی. ولی روی کاربرانتون تاثیر مثبت میذاره!

 

  • نکات و مشکلات

1- مفهوم اعداد منفی در بعضی مشخصه های version چیه؟

خیلی کم پیش میاد ولی معمولاً بیانگر roll-back ایه که بخاطر critical bug fix یا حذف یک feature انجام گرفته.

2- آیا استفاده از دیگر کاراکترهایی مثل - / _ در بین مشخصه های Major Minor Revision/Patch کار درستیه؟

خیر. چون این کاراکترها جایگزین SPACE و خط فاصله در نامگذاری فایلها برای جداسازی و خوانایی بهتر هستند.

مثل: 2015-php-5.4.2.3485-x86-rc2. حالا تصور کنید که اگر استفاده بشه: php-5-4-2-3485-x86-rc2-2015-11-22

3- اگر dependency رو آپدیت کردم کدوم مشخصه رو تغییر بدم؟

معمولاً به میزان تعداد dependency های آپدیت شده، عدد Revision/Patch رو 1 تا 5 واحد افزایش میدن.

4- اگر document رو آپدیت کردم کدوم مشخصه رو تغییر بدم؟

معمولاً به میزان حجم آپدیت، عدد Revision/Patch رو 1 تا 3 واحد افزایش میدن.

 

یاد آوری: درحال حاضر استاندارد رسمی برای اصول Versioning وجود نداره اما اصول و قوائدی وجود دارن که با تبعیت از اونا میشه به نتیجه مطلوبی رسید.

من هم در این مقاله از اون قوائد(قوائد Gnu، مستندات Eclipse, سبک Semantic و...) پیروی کردم.

 

نظرات (۷)

۰۲ فروردين ۹۶ ، ۱۹:۵۵ فاروق کریمی زاده
آماده نیست، یا اونطور که باید باشه اما نیست اما منتشر شده، وقتی منتشر نشده که نیازی به نسخه زدن نیست!
پاسخ:
سلیقه ایه دیگه... اختلاف بین علماست :)


اما وقتی هم که منتظر نشده - حالت pre-alpha یا develop داره - هم میتونه نسخه بندی بشه، اما زمانی که ترخیص میشه ریست بشه. یا کماکان عددش حفظ بشه
مثل JDK و JRE قدیمی شرکت Sun که نسخه داخلی هم داشتن
مثل اندروید 1 و قبلتر گوگل که ترخیص نشد و فقط داخلی بود
مثل بعضی محصولات مایکروسافت که اولین نسخشون شماره build بالایی دارن
و...
۰۱ فروردين ۹۶ ، ۲۰:۱۵ فاروق کریمی زاده
بنظرم خوبه بعضی مواقع از صفر شروع بکنیم، وقتی هنوز نرم افزار آماده نیست، نسخه یک صدم کرنل لینوکس با این که اولین نسخش بود اما تقریبا هیچی نداشت، حتی فلاپی هم نمیشناخت، واسه همچین چیزی به نظرم همون یک صدم بهتر از یک هست.
پاسخ:
وقتی نرم افزار آماده نیست(منتشر نشده) یا آمادست(منتشر شده) اما کامل نیست؟
۰۱ فروردين ۹۶ ، ۱۴:۲۷ فاروق کریمی زاده
توی منابعتون نوشته بودید قواسد گنو، میشه یک لینک به اونا هم بدید
پاسخ:
الان یادم نیست همشون اما:
https://en.wikipedia.org/wiki/Software_versioning#Incrementing_sequences

۰۱ فروردين ۹۶ ، ۱۴:۲۵ فاروق کریمی زاده
https://ftp.gnu.org/old-gnu/aspell/
https://ftp.gnu.org/old-gnu/zlibc/
همچنین خود کرنل لینوکس
بعد این فایرفاکس چشه؟هر دو دقیقه یک بار یه دونه major اضاقه میکنه!
پاسخ:
Slackware Linux
http://www.nielshorn.net/slackware/slack_versions.php

FreeBSD
https://en.wikipedia.org/wiki/FreeBSD_version_history#Version_history

همونطور که گفتم، بعضی محصولات از 0 شروع می کنن، اما اکثراً(80-90 درصد) از 1 شروع می کنن...
چون طبیعتاً اولین نسخه محصول هستش، پس 1 مناسب تره
۳۰ اسفند ۹۵ ، ۱۵:۵۲ فاروق کریمی زاده
در مورد مایکروسافت آفیس فکرم کنم مایکروسافت آفیس ۲۰۱۷ یک نرم افزار جدید هستـش
در مورد major هم بعضیا از صفر شروع میکنن، این یعنی اینکه هنوز آماده استفاده عمومی نشده، درسته؟
این ویساپسیس بر چه اساس میره جلو؟
visopsys.org
کاش چند تا لینک هم به منابعت میدادی
++
پاسخ:
شروع major از صفر خوانایی و وضوح version رو پایین میاره... 80-90 درصد نرم افزارها از 1 شروع می کنن. حتی خودروها

1.0.0
https://en.wikipedia.org/wiki/Android_version_history

1.0.0
https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions#Client_versions

1.0
https://en.wikipedia.org/wiki/BlackBerry_OS

1.0
http://filehippo.com/download_firefox/15/

1.0
http://filehippo.com/download_thunderbird/history/26/

1.0.0
https://en.wikipedia.org/wiki/IOS_version_history


منابع:
http://semver.org/spec/v2.0.0.html
https://wiki.eclipse.org/Version_Numbering
۰۲ دی ۹۵ ، ۲۱:۱۴ فرهاد حسن‌پور
برای اونام یه عدد کنار میزارم :-)
۰۳ آذر ۹۵ ، ۱۷:۵۰ فرهاد حسن‌پور
مقاله جالبی بود ولی من یه روش برای خودم به شرح زیر ساختم

مثلا :‌ ۲.۳.۴
به تر تیب از چپ : (۲) نسخه نرم افزار
(۳) رفع مشکلات و باگ امنیتی
(۴) افزودن امکانات جزیی یا اصلاحات جزیی

با هر بار تغییرات یه عددها بالا میرن.

پاسخ:
در مورد کتابخانه ها چطور؟
اگر تغییر در API کتابخانه بدی از کجا اونوقت تشخیص میدی؟ یا کاربرات تشخیص میدن؟
کاربران بیان میتوانند بدون نیاز به تأیید، نظرات خود را ارسال کنند.
اگر قبلا در بیان ثبت نام کرده اید لطفا ابتدا وارد شوید، در غیر این صورت می توانید ثبت نام کنید.