تغییر زمانبندی انتشار Node.js

تغییر زمانبندی انتشار Node.js

انتشار:

Node.js از نسخه 27 به بعد، به جای دو انتشار اصلی (Major Release) در هر سال، تنها یک انتشار اصلی خواهد داشت. در این مطلب بررسی می‌کنیم که به چه دلیل این تصمیم گرفته شده و این موضوع چه تاثیری برای کاربران آن دارد. این مطلب ترکیبی از ترجمه متن رسمی و برداشت‌های شخصی من از موضوع است؛
این تغییر زمانبندی شاید در ظاهر فقط یه تغییر مدیریتی به نظر بیاد، ولی در واقع یک حقیقت مهم درباره Node.js را رسمی می‌کند: تقریباً هیچ‌کس با ریلیزهای non-LTS کار نمی‌کند. سال‌ها Node دو انتشار اصلی در سال داشت؛ ورژن زوج که بعدا LTS می‌شد و ورژن فرد که عملا نقش محیط آزمایشی را داشت. روی کاغذ منطقی بود، ولی در عمل اکثر استفاده کنندگان و خیلی از توسعه‌دهنده‌ها مستقیم منتظر LTS می‌ماندند. در نتیجه نسخه‌های فرد مثل 21 یا 23 کارایی نداشتند و همه منتظر نسخه‌های زوج بودند.

از طرفی تیم Node یجورایی داره میگه مشکل فقط فنی نیست، مشکل تجربی و عملی هم هست. پروژه‌ای با این ابعاد هنوز تا حد زیادی توسط داوطلب‌ها نگهداری میشه و نگهداری همزمان ۴ یا ۵ release line فعال، مخصوصا برای backportهای امنیتی، عملاً فرساینده شده. این بخش اطلاعیه خیلی مهمه چون برخلاف خیلی از پروژه‌های بزرگ، Node داره اعتراف می‌کنه که sustainability از pure feature velocity مهم‌تر شده.

تغییر مهم بعدی حذف کامل مفهوم odd/even release هست. از Node 27 به بعد، هر نسخه‌ای که منتشر بشه در نهایت LTS خواهد شد. این یعنی version number دیگر "نسخه آزمایشی" یا "نسخه واقعی" معنی نمی‌دهد. برای شرکت‌ها این قابل پیش‌بینی تره، ولی از یه زاویه دیگه هم جالبه: Node داره release cycle خودش رو بیشتر شبیه distroهای پایدار لینوکس یا حتی زبان‌هایی مثل Python می‌کنه؛ کمتر هیجان‌زده، بیشتر قابل برنامه‌ریزی.

اما شاید مهم‌ترین تغییر واقعی، معرفی Alpha channel باشه. قبلا نسخه‌های فرد عملا نقش تست رو داشتن، ولی حالا Node میگه testing باید هدفمندتر باشه، نه accidental. Alphaها اجازه‌ی semver-major change میدن و با ابزارهایی مثل CITGM روی پکیج‌های مهم ecosystem تست میشن. این یعنی تیم Node داره تلاش می‌کنه breaking changeها قبل از رسیدن به production ecosystem کشف بشن، نه بعدش.

یه نکته‌ای هم که بین خطوط دیده میشه، ارتباط مستقیم این تغییر با سرعت رشد خود JavaScript و V8 هست. وقتی هر چند ماه یک قابلیت جدید، runtime API جدید یا تغییر بزرگ وارد زبان میشه، مدیریت cadence قبلی سخت‌تر شده. Alpha channel عملاً به Node فضای بیشتری میده تا تغییرات سنگین مثل Temporal، FFI یا تغییرات V8 رو زودتر وارد چرخه کنه بدون اینکه کل release train به‌هم بریزه.

برای library maintainerها اما این تغییر یه هشدار جدی محسوب میشه. متن اصلی از وبلاگ Node تقریبا مستقیم میگه اگر فقط روی LTS تست کنید، عملا دیر متوجه breaking changeها میشید و وقتی کاربرها آسیب دیدن تازه باگ report می‌کنید. یعنی مسئولیت compatibility حالا بیشتر از قبل به دوش توسعه دهنده‌های پکیج‌ها افتاده.

در کل، این تصمیم بیشتر از اینکه درباره “کم کردن تعداد ریلیزها” باشه، درباره بالغ‌تر شدن اکوسیستم Node عه. ده سال پیش هدف رشد سریع بود؛ الان هدف اینه که اکوسیستم عظیم امروزی، قابل نگهداری و قابل پیش‌بینی باقی بمونه.

به نظرم این تغییر، Node.js را از نظر چرخه انتشار به سمت همان الگویی می‌برد که سال اخیر در بسیاری از نرم‌افزارها دیده‌ایم؛ یعنی هم‌راستا شدن نسخه‌ها با سال انتشار (میلادی). شاید این تصمیم مستقیما تحت تاثیر Apple نباشد، اما نمی‌توان نادیده گرفت که شرکت‌هایی مانند Apple با چرخه‌های انتشار منظم و سالانه، روی انتظارات کل صنعت نرم‌افزار تاثیر گذاشته‌اند و بسیاری از پروژه‌ها نیز به سمت مدل‌های مشابه حرکت کرده‌اند. در نهایت این موضوع شاید در نگاه اول صرفاً یک تغییر ظاهری باشد، اما در عمل مزایایی هم دارد. تشخیص قدیمی یا جدید بودن نسخه‌ها ساده‌تر می‌شود، برنامه‌ریزی برای مهاجرت نسخه‌ها در سازمان‌ها و شرکت‌ها قابل پیش‌بینی‌تر خواهد بود و ارتباطات و مستندسازی نیز شفاف‌تر می‌شود.

 

منبع:

https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule