Yousha
جمعه 27 شهریور 1394, 17:46 عصر
Version چیست
Version یا همون نسخه، مشخصه ای برای دسته بندی وضعیت محصول منتشر شده و [مختصر] شرحی از تغییرات انجام گرفته هستش.
به این معنی که Version یک محصول، بیانگر حال و روز کنونی و مقدار بهبود یافتگی اون محصول هستش... یا حتی آینده ای که در انتظارشه
مشخصه Version می تونه بصورت عدد، کلمه و تاریخ باشه; یا حتی هر سه:
Major.Minor.Micro/Patch[-Build] [ReleaseState] [Architecture] [Date] [Time]
توجه: همونطور که می دونید استاندارد و تعریف رسمی برای مشخصه ها و اصطلاحات وجود نداره ولی در این مقاله سعی می کنم معمول ترین و کاملترین تعریف رو از قوائد Gnu، مستندات Eclipse (https://wiki.eclipse.org/Version_Numbering), سبک Semantic (http://semver.org/spec/v2.0.0.html) و غیره برای اینها انجام بدم...
مثال:
MyProgram 1.0.0 i486: یعنی این اولین انتشار MyProgram هستش و برای سخت افزارهای 32 بیتی i486, i586, i686 و جدیدتر طراحی شده.
MyProgram 1.7.5 beta w32: یعنی این چندمین انتشار 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 A x64 2015/11/21 13:30: یعنی این انتشار نسخه 3 MyLibrary هستش، تغییرات گسترده ای صورت گرفته و public API برنامه هم شکست داشته و با نسخه های قدیمیش سازگار نیست(2 و 1)، تا الان 44 بار build/compile شده، یرای سخت افزار های x64 طراحی شده، همچنین نسخه آزمایشی(Alpha) هه و باگ زیاد داره، حفره امنیتی داره، امکان از دست رفتن دیتای کاربر وجود داره و 70% امکان داره تغییرات خیلی بیشتری درش صورت بگیره یا حتی تغییرات قبلی rollback بشن، خیلی زود هم نسخه جدیدتری عرضه خواهد شد، در تاریخ 2015/11/21 در ساعت 13:30 منتشر شده.
Google Chrome 3160482924.76: ؟!
Microsoft Office 2020: اینم فقط بیانگر نسخه جدید Microsoft Office و اومدنه سال نو هستش...
اینگونه versioning بندی اشتباه و 100% مارکتینگ هستش. می بینید که هیچ گونه اطلاعاتی راجب نسخه منتشر شده وجود نداره، تا زمانی که اون محصول رو بخرید/دانلود کنید و بعد هم نصبش کنید. تازه می فهمید چیه و چه اشتباهی کردید...!
در واقع Version یک محصول، شرح حال و چشم انداز اون محصول رو توضیح میده. با تفسیر درست Version میتونید اطلاعات کاملی راجب محصول بدست بیارید که بسیار در تصمیم گیری(برای استفاده یا بروزرسانی) کمکتون می کنه.
اصول Versioning
برای Versioning درحال حاضر استاندارد رسمی وجود نداره اما اصول و قوائدی وجود دارن که با تبعیت از اونا میشه به نتیجه مطلوبی رسید. که من هم در این مقاله از اون قوائد(که شامل برخی مستندات RFC، قوائد Gnu، مستندات Eclipse, سبک Semantic و...) پیروی می کنم.
شمای معمول یک Version مناسب و کامل به این صورته:
Major.Minor.Micro/Patch[-Build] [ReleaseState] [Architecture] [Date] [Time]
توجه: واژه های داخل گیومه [] اختیاری هستند یا در بعضی از نرم افزار ها قادر به استفاده از اونها نیستید.
Major
مقدارش چیه؟ اعداد صحیح مثبت و برای انتشار عمومی از 1 شروع میشه.
چه زمانی عددشو تغییر بدیم؟
زمانی که شکست در public API نرم افزار صورت بگیره. (در حدی که کاربر نتونه نسخه جدید رو نسخه قدیم سازگار کنه (مثل library ها))
یا شیوه کار با نرم افزار تغییر کنه.
یا دگرگونی های اساسی و گسترده ای صورت بگیره.
چه تاثیری روی بقیه مشخصه ها میذاره؟ درصورت تغییر این عدد Major، عدد Minor و عدد Micro/Patch مجدداً به 0 ریست می شن.
مثال: در نسخه 2.4.6 نرم افزار، یک تغییر در API صورت گرفت، پس نسخه جدید میشه 3.0.0.
نکته: اگر عدد Major تغییر کنه، دیگه نباید سعی کنید نرم افزار رو با نسخه های قبلیش سازگار کنید. مگر اینکه هدف Backward compatibility باشه.
نکته 2: اگر نرم افزار در اولین فاز توسعه قرار داره و هنوز در دسترس عموم قرار نگرفته، در این صورت فقط عدد Minor و عدد Micro/Patch تغییر می کنن (مثل 0.1.0, 0.1.1, 0.2.3 و...) یا جدای از نسخه عمومی، یک نسخه داخلی هم برای نرم افزار درنظر گرفته میشه.
Minor
مقدارش چیه؟ اعداد صحیح مثبت و از 0 شروع میشه.
چه زمانی عددشو تغییر بدیم؟
زمانی که امکان جدید اضافه میشه.
زمانی که تغییرات جزئی در public API نرم افزار صورت بگیره. (در حدی که کاربر بتونه با تغییراتی در نرم افزار/دیتا خودش با نسخه جدید سازگار بشه)
یا ظاهر نرم افزار تغییر پیدا میکنه.
یا تعدادی امکانات جدید کوچیک اضافه میشه.
یا یک ماژول/کامپونت اضافه میشه.
یا performance به مقدار قابل توجهی افزایش پیدا میکنه.
یا روی بخش عمده ای از کد دوباره کار میشه.
چه تاثیری روی بقیه مشخصه ها میذاره؟ درصورت تغییر عدد Minor ، عدد Micro/Patch مجدداً به 0 ریست می شن.
مثال: در نسخه 2.4.7 نرم افزار، یک ماژول اضافه شده، performance هم افزایش پیدا کرده، پس نسخه جدید میشه 2.5.0.
Micro/Patch
مقدارش چیه؟ اعداد صحیح مثبت و از 0 شروع میشه.
چه زمانی عددشو تغییر بدیم؟
زمانی که تغییرات جزئی در کدها صورت بگیره.
یا باگ fix بشه.
یا مستندات نرم افزار تغییر پیدا کنن.
یا بهبود های جزیی صورت بگیره.
یا security patch انجام بگیره.
یا dependency ای upgrade بشه. (با internal-library ها اشتباه نگیرید)
چه تاثیری روی بقیه مشخصه ها میذاره؟ اغلب هیچی
مثال: در نسخه 1.0.3 نرم افزار، مستندات نرم افزار بروز شدن، تعدادی از dependency ها upgrade شدن، کمی بهبود در کدها صورت گرفت، پس نسخه جدید میشه 1.0.6.
Build
این مشخصه تعیین می کنه که نرم افزار چند بار compile/build/release شده. (یا در بعضی موارد فقط خطای داخلی رفع شده)
مقدارش چیه؟ اعداد صحیح مثبت و از 1 شروع میشه.
چه زمانی عددشو تغییر بدیم؟
در هربار که نسخه جدیدی compile یا build یا release می کنید یک واحد عددشو بالا می برید.
یا خودش بصورت خودکار در هربار compile یک واحد افزایش پیدا می کنه.
چه تاثیری روی بقیه مشخصه ها میذاره؟ هیچی
مثال: در نسخه 1.0.0.1 نرم افزار، یک ماژول اضافه شده، performance هم افزایش پیدا کرده، تعدادی امکانات جدید کوچیک اضافه شد، ظاهر نرم افزار تغییر کرد، مستندات نرم افزار بروز شدن، تعدادی از dependency ها upgrade شدن، کمی بهبود در کدها صورت گرفت، پس نسخه جدید میشه 1.4.0.2.
Architecture
این مشخصه معمولاً کاربردش در نرم افزارهای باینری و تحت دسکتاپ(از هر نوعش) هستش. و مشخص می کنه که نرم افزار برای چه سیستم عامل یا سخت افزاری طراحی شده.
مقدارش چیه؟ x86, x64, i386, i486, ia64, arm, w64, powerpc, sun3, w32 و...
چه تاثیری روی بقیه مشخصه ها میذاره؟ هیچی
ReleaseState
این مشخصه از مرحله ای که کلنگ انجام پروژه زده میشه(initial) و تا مرحله ای که به نسخه Production برسه بصورت خودکار معلوم میشه. در واقع این مشخصه بیانگر کیفیت کنونی و چشم انداز نرم افزار هستش. کاربران هم از روی این مشخصه تصمیم میگیرن که از اون نرم افزار [در حال حاضر] استفاده کنند یا خیر.
مقدارش چیه؟ معمولاً Alpha, Beta, Closed beta, Open beta, RC, Develop, 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 ش تعیین می کنن.
Continuous beta: این نوع وضعیت معمولاً شماره نسخه ندارن و مخصوص نرم افزارهای مبتنی بر cloud هستش که بر روی هاست نصب هستن. و همیشه نرم افزار جدیدترین نسخه اش هستش. مثل Google Search, Gmail, Bing
البته مشخصه های دیگه ای هم مثل 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 Micro/Patch کار درستیه؟
خیر. چون این کاراکترها جایگزین SPACE و خط فاصله در نامگذاری فایلها برای جداسازی و خوانایی بهتر هستند.
مثل: 2015-php-5.4.2.3485-x86-rc2. حالا تصور کنید که اگر استفاده بشه: php-5-4-2-3485-x86-rc2-2015-11-22
3- اگر dependency رو upgrade کردم کدوم مشخصه رو تغییر بدم؟
معمولاً به میزان تعداد dependency های upgrade شده، عدد Micro/Patch رو 1 تا 5 واحد افزایش میدن.
4- اگر document رو آپدیت کردم کدوم مشخصه رو تغییر بدم؟
معمولاً به میزان حجم آپدیت، عدد Micro/Patch رو 1 تا 3 واحد افزایش میدن.
یاد آوری: درحال حاضر استاندارد رسمی برای اصول Versioning وجود نداره اما اصول و قوائدی وجود دارن که با تبعیت از اونا میشه به نتیجه مطلوبی رسید.
من هم در این مقاله از اون قوائد(Gnu، مستندات Eclipse (https://wiki.eclipse.org/Version_Numbering), سبک Semantic (http://semver.org/spec/v2.0.0.html) و...) پیروی کردم.
منبع: http://yousha.blog.ir/post/70
Version یا همون نسخه، مشخصه ای برای دسته بندی وضعیت محصول منتشر شده و [مختصر] شرحی از تغییرات انجام گرفته هستش.
به این معنی که Version یک محصول، بیانگر حال و روز کنونی و مقدار بهبود یافتگی اون محصول هستش... یا حتی آینده ای که در انتظارشه
مشخصه Version می تونه بصورت عدد، کلمه و تاریخ باشه; یا حتی هر سه:
Major.Minor.Micro/Patch[-Build] [ReleaseState] [Architecture] [Date] [Time]
توجه: همونطور که می دونید استاندارد و تعریف رسمی برای مشخصه ها و اصطلاحات وجود نداره ولی در این مقاله سعی می کنم معمول ترین و کاملترین تعریف رو از قوائد Gnu، مستندات Eclipse (https://wiki.eclipse.org/Version_Numbering), سبک Semantic (http://semver.org/spec/v2.0.0.html) و غیره برای اینها انجام بدم...
مثال:
MyProgram 1.0.0 i486: یعنی این اولین انتشار MyProgram هستش و برای سخت افزارهای 32 بیتی i486, i586, i686 و جدیدتر طراحی شده.
MyProgram 1.7.5 beta w32: یعنی این چندمین انتشار 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 A x64 2015/11/21 13:30: یعنی این انتشار نسخه 3 MyLibrary هستش، تغییرات گسترده ای صورت گرفته و public API برنامه هم شکست داشته و با نسخه های قدیمیش سازگار نیست(2 و 1)، تا الان 44 بار build/compile شده، یرای سخت افزار های x64 طراحی شده، همچنین نسخه آزمایشی(Alpha) هه و باگ زیاد داره، حفره امنیتی داره، امکان از دست رفتن دیتای کاربر وجود داره و 70% امکان داره تغییرات خیلی بیشتری درش صورت بگیره یا حتی تغییرات قبلی rollback بشن، خیلی زود هم نسخه جدیدتری عرضه خواهد شد، در تاریخ 2015/11/21 در ساعت 13:30 منتشر شده.
Google Chrome 3160482924.76: ؟!
Microsoft Office 2020: اینم فقط بیانگر نسخه جدید Microsoft Office و اومدنه سال نو هستش...
اینگونه versioning بندی اشتباه و 100% مارکتینگ هستش. می بینید که هیچ گونه اطلاعاتی راجب نسخه منتشر شده وجود نداره، تا زمانی که اون محصول رو بخرید/دانلود کنید و بعد هم نصبش کنید. تازه می فهمید چیه و چه اشتباهی کردید...!
در واقع Version یک محصول، شرح حال و چشم انداز اون محصول رو توضیح میده. با تفسیر درست Version میتونید اطلاعات کاملی راجب محصول بدست بیارید که بسیار در تصمیم گیری(برای استفاده یا بروزرسانی) کمکتون می کنه.
اصول Versioning
برای Versioning درحال حاضر استاندارد رسمی وجود نداره اما اصول و قوائدی وجود دارن که با تبعیت از اونا میشه به نتیجه مطلوبی رسید. که من هم در این مقاله از اون قوائد(که شامل برخی مستندات RFC، قوائد Gnu، مستندات Eclipse, سبک Semantic و...) پیروی می کنم.
شمای معمول یک Version مناسب و کامل به این صورته:
Major.Minor.Micro/Patch[-Build] [ReleaseState] [Architecture] [Date] [Time]
توجه: واژه های داخل گیومه [] اختیاری هستند یا در بعضی از نرم افزار ها قادر به استفاده از اونها نیستید.
Major
مقدارش چیه؟ اعداد صحیح مثبت و برای انتشار عمومی از 1 شروع میشه.
چه زمانی عددشو تغییر بدیم؟
زمانی که شکست در public API نرم افزار صورت بگیره. (در حدی که کاربر نتونه نسخه جدید رو نسخه قدیم سازگار کنه (مثل library ها))
یا شیوه کار با نرم افزار تغییر کنه.
یا دگرگونی های اساسی و گسترده ای صورت بگیره.
چه تاثیری روی بقیه مشخصه ها میذاره؟ درصورت تغییر این عدد Major، عدد Minor و عدد Micro/Patch مجدداً به 0 ریست می شن.
مثال: در نسخه 2.4.6 نرم افزار، یک تغییر در API صورت گرفت، پس نسخه جدید میشه 3.0.0.
نکته: اگر عدد Major تغییر کنه، دیگه نباید سعی کنید نرم افزار رو با نسخه های قبلیش سازگار کنید. مگر اینکه هدف Backward compatibility باشه.
نکته 2: اگر نرم افزار در اولین فاز توسعه قرار داره و هنوز در دسترس عموم قرار نگرفته، در این صورت فقط عدد Minor و عدد Micro/Patch تغییر می کنن (مثل 0.1.0, 0.1.1, 0.2.3 و...) یا جدای از نسخه عمومی، یک نسخه داخلی هم برای نرم افزار درنظر گرفته میشه.
Minor
مقدارش چیه؟ اعداد صحیح مثبت و از 0 شروع میشه.
چه زمانی عددشو تغییر بدیم؟
زمانی که امکان جدید اضافه میشه.
زمانی که تغییرات جزئی در public API نرم افزار صورت بگیره. (در حدی که کاربر بتونه با تغییراتی در نرم افزار/دیتا خودش با نسخه جدید سازگار بشه)
یا ظاهر نرم افزار تغییر پیدا میکنه.
یا تعدادی امکانات جدید کوچیک اضافه میشه.
یا یک ماژول/کامپونت اضافه میشه.
یا performance به مقدار قابل توجهی افزایش پیدا میکنه.
یا روی بخش عمده ای از کد دوباره کار میشه.
چه تاثیری روی بقیه مشخصه ها میذاره؟ درصورت تغییر عدد Minor ، عدد Micro/Patch مجدداً به 0 ریست می شن.
مثال: در نسخه 2.4.7 نرم افزار، یک ماژول اضافه شده، performance هم افزایش پیدا کرده، پس نسخه جدید میشه 2.5.0.
Micro/Patch
مقدارش چیه؟ اعداد صحیح مثبت و از 0 شروع میشه.
چه زمانی عددشو تغییر بدیم؟
زمانی که تغییرات جزئی در کدها صورت بگیره.
یا باگ fix بشه.
یا مستندات نرم افزار تغییر پیدا کنن.
یا بهبود های جزیی صورت بگیره.
یا security patch انجام بگیره.
یا dependency ای upgrade بشه. (با internal-library ها اشتباه نگیرید)
چه تاثیری روی بقیه مشخصه ها میذاره؟ اغلب هیچی
مثال: در نسخه 1.0.3 نرم افزار، مستندات نرم افزار بروز شدن، تعدادی از dependency ها upgrade شدن، کمی بهبود در کدها صورت گرفت، پس نسخه جدید میشه 1.0.6.
Build
این مشخصه تعیین می کنه که نرم افزار چند بار compile/build/release شده. (یا در بعضی موارد فقط خطای داخلی رفع شده)
مقدارش چیه؟ اعداد صحیح مثبت و از 1 شروع میشه.
چه زمانی عددشو تغییر بدیم؟
در هربار که نسخه جدیدی compile یا build یا release می کنید یک واحد عددشو بالا می برید.
یا خودش بصورت خودکار در هربار compile یک واحد افزایش پیدا می کنه.
چه تاثیری روی بقیه مشخصه ها میذاره؟ هیچی
مثال: در نسخه 1.0.0.1 نرم افزار، یک ماژول اضافه شده، performance هم افزایش پیدا کرده، تعدادی امکانات جدید کوچیک اضافه شد، ظاهر نرم افزار تغییر کرد، مستندات نرم افزار بروز شدن، تعدادی از dependency ها upgrade شدن، کمی بهبود در کدها صورت گرفت، پس نسخه جدید میشه 1.4.0.2.
Architecture
این مشخصه معمولاً کاربردش در نرم افزارهای باینری و تحت دسکتاپ(از هر نوعش) هستش. و مشخص می کنه که نرم افزار برای چه سیستم عامل یا سخت افزاری طراحی شده.
مقدارش چیه؟ x86, x64, i386, i486, ia64, arm, w64, powerpc, sun3, w32 و...
چه تاثیری روی بقیه مشخصه ها میذاره؟ هیچی
ReleaseState
این مشخصه از مرحله ای که کلنگ انجام پروژه زده میشه(initial) و تا مرحله ای که به نسخه Production برسه بصورت خودکار معلوم میشه. در واقع این مشخصه بیانگر کیفیت کنونی و چشم انداز نرم افزار هستش. کاربران هم از روی این مشخصه تصمیم میگیرن که از اون نرم افزار [در حال حاضر] استفاده کنند یا خیر.
مقدارش چیه؟ معمولاً Alpha, Beta, Closed beta, Open beta, RC, Develop, 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 ش تعیین می کنن.
Continuous beta: این نوع وضعیت معمولاً شماره نسخه ندارن و مخصوص نرم افزارهای مبتنی بر cloud هستش که بر روی هاست نصب هستن. و همیشه نرم افزار جدیدترین نسخه اش هستش. مثل Google Search, Gmail, Bing
البته مشخصه های دیگه ای هم مثل 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 Micro/Patch کار درستیه؟
خیر. چون این کاراکترها جایگزین SPACE و خط فاصله در نامگذاری فایلها برای جداسازی و خوانایی بهتر هستند.
مثل: 2015-php-5.4.2.3485-x86-rc2. حالا تصور کنید که اگر استفاده بشه: php-5-4-2-3485-x86-rc2-2015-11-22
3- اگر dependency رو upgrade کردم کدوم مشخصه رو تغییر بدم؟
معمولاً به میزان تعداد dependency های upgrade شده، عدد Micro/Patch رو 1 تا 5 واحد افزایش میدن.
4- اگر document رو آپدیت کردم کدوم مشخصه رو تغییر بدم؟
معمولاً به میزان حجم آپدیت، عدد Micro/Patch رو 1 تا 3 واحد افزایش میدن.
یاد آوری: درحال حاضر استاندارد رسمی برای اصول Versioning وجود نداره اما اصول و قوائدی وجود دارن که با تبعیت از اونا میشه به نتیجه مطلوبی رسید.
من هم در این مقاله از اون قوائد(Gnu، مستندات Eclipse (https://wiki.eclipse.org/Version_Numbering), سبک Semantic (http://semver.org/spec/v2.0.0.html) و...) پیروی کردم.
منبع: http://yousha.blog.ir/post/70