سیاست های نسخه بندی در React

ری اکت از اصول نسخه بندی معنایی (semver) پیروی می‌کند.

این یعنی در نسخه‌ای با شمارۀ x.y.z :

  • هنگام تغییر بخشی از سیستم نرم افزار، ما با تغییر عدد x انتشار major خواهیم داشت. (مثلا ۶.۲ به ۱۶.۰.۰)
  • هنگام منتشر کردن برخی قابلیت های جدید، ما با تغییر عدد y انتشار minor خواهیم داشت. (مثلا ۶.۲ به ۱۵.۷.۰)
  • هنگام اصلاح برخی باگ‌ها، ما با تغییر عدد z انتشار patch خواهیم داشت. (مثلا ۶.۲ به ۱۵.۶.۳)

انتشار major می‌تواند شامل قابلیت های جدید هم باشد و هر انتشاری می‌تواند شامل اصلاح برخی باگ‌ها باشد.

تغییر بخشی از سیستم نرم افزار (Breaking Changes)

تغییر بخشی از سیستم نرم افزار برای هیچکس راحت نیست و ما تلاش می‌کنیم تعداد انتشار major را به حداقل برسانیم. برای مثال ری اکت ۱۵ در آپریل ۲۰۱۶ منتشر شد و ری اکت ۱۶ در آپریل ۲۰۱۷ منتشر شد؛ ری اکت ۱۷ نیز انتظار نمی‌رود تا سال ۲۰۱۹ منتشر شود.

در مقابل، ما قابلیت های جدید را در نسخه‌های minor منتشر می‌کنیم. این یعنی انتشارات minor اغلب جالب و مناسب هستند، با وجو اینکه نام بی ادعایی دارند.

تعهد به ثبات

با وجود اینکه در طول زمان React را تغییر می‎دهیم، اما سعی می‌کنیم تلاش مورد نیاز شما برای به کار گیری و یادگیری قابلیت های جدید را به حداقل برسانیم. تا زمانی که ممکن باشد، یک API قدیمی را برای انجام کار حفظ می‌کنیم، حتی اگر باعث شود آن را در پکیج جداگانه‌ای قرار دهیم. برای مثال سال‌هاست که mixins مورد اقبال نیست اما همچنان تا کنون به وسیلۀ create-react-class پشتیبانی شده و بسیاری از کدبیس ها به استفاده از آنها در کدهای ارثی باثبات ادامه می‌دهند.

بیش از یک میلیون برنامه نویس از React استفاده می‌کنند و در مجموع میلیون ها کامپوننت مورد استفاده قرار گرفته است. کدبیس فیسبوک به تنهایی بیش از ۵۰۰۰۰ کامپوننت React دارد. این یعنی ما باید آپگرید نسخه‌های جدید React را تا جایی که می‌شود آسان کنیم. اگر تغییرات بزرگی را بدون یک مسیر درست اعمال کنیم، مردم در نسخه‌های قدیمی گیر خواهند کرد. ما این مسیرهای آپگرید را در خود فیسبوک تست می‌کنیم و اگر تیم ما که کمتر از ۱۰ نفر است بتواند بیش از ۵۰۰۰۰ کامپوننت را آپدیت کند، بنابراین امیدوار خواهیم بود که آن آپگرید برای همۀ کسانی که با React کار می‌کنند قابل مدیریت خواهد بود. در بسیاری از موارد ما اسکریپت های خودکاری را برای سینتکس آپگرید کامپوننت می‌نویسیم که می‌تواند در ادامه داخل نسخۀ open-source و برای استفادۀ همه قرار گیرد.

آپگریدهای تدریجی از طریق هشدارها

نسخه‌های ری اکت شامل هشدارهای کمک کننده‌ای هستند. هروقت که ممکن باشد، ما هشدارهایی را در آماده سازی Breaking Change های آینده اضافه می‌کنیم. به این صورت که اگر برنامه شما در آخرین نسخه‌ای که دارید هیچ هشداری نداشته باشد، با انتشار major بعدی هم مشکلی نخواهد داشت.

هشدارهای برنامه نویسی رفتار زمان اجرای برنامه شما را تحت تاثیر قرار نمی‌دهند. در این صورت می‌توانید مطمئن باشید که برنامه شما در زمان توسعه و تولید نسخه‌ها یکسان عمل می‌کند. تنها تفاوت در این است که در نسخه‌های تولید  هشدارها وارد نمی‌شوند.

چه چیزی به عنوان یک Breaking Change لحاظ می‌شود؟

به طور کلی ما عدد نسخۀ major را به خاطر موارد زیر تغییر نمی‌دهیم:

  • هشدارهای برنامه نویسی. از آنجایی که این هشدارها رفتار تولیدات را تغییر نمی‌دهند، ممکن است گاهی هشدارهایی را اضافه کنیم و یا برخی هشدارهای موجود را در بین نسخه‌های major ویرایش کنیم. در حقیقت این کار به ما اجازه می‌دهد نسبت به Breaking Change آینده هشدار دهیم.
  • API هایی که با unstable_ شروع می‌شوند. اینها به عنوان قابلیت‌های آزمایشی که هنوز نسبت به آنها اطمینان نداریم مهیا شده‌اند. با انتشار آنها با پیشوند unstable_ می‌توانیم تکرارها را سریع‌تر انجام داده و زودتر به یک API پایدار برسیم.
  • نسخه‌های آلفای ری اکت. ما نسخه‌های آلفای ری اکت را آماده می‌کنیم تا به زودی بتوانیم قابلیت‌های جدید را تست کنیم اما نیاز به انعطاف پذیری داریم تا تغییرات را بر اساس چیزهایی که در نسخۀ آلفا یاد گرفتیم اعمال کنیم. اگر از این نسخه‌ها استفاده می‌کنید دقت کنید که API ها ممکن است تغییر کنند.
  • API های مستند نشده و ساخارهای داخلی دیتا. اگر به نام‌های مشخصات داخلی مانند __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED و یا __reactInternalInstance$uk43rzhitjg دسترسی دارید، هیچ تضمینی وجود ندارد. مسئولیتش با خودتان است.

این سیاست‌ها طوری طراحی شده که واقع‌بینانه و عملگرا باشند. قطعا دنبال این نیستیم که دردسری برای شما ایجاد کنیم. اگر برای همۀ این تغییرات نسخۀ major منتشر می‌کردیم دردسر زیادی ایجاد می‌کرد. این یعنی با هر سرعتی که بخواهیم نمی‌توانیم باعث رشد React شویم و باید کنترل شده حرکت کنیم.

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

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5٫00 out of 5)
Loading...

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

counter customizable free hit