تقویم جدید Node.js از اکتبر ۲۰۲۶: پایان نسخه‌های فرد و برنامه مهاجرت تیم‌ها

سال‌ها یک قاعده ساده در ذهن توسعه‌دهندگان Node.js بود: نسخه‌های زوج به LTS می‌رسند و نسخه‌های فرد عمر کوتاهی دارند. این میان‌بُر از اکتبر ۲۰۲۶ دیگر دقیق نیست. پروژه Node.js رسماً چرخه انتشار خود را تغییر می‌دهد؛ از نسخه ۲۷ فقط یک نسخه اصلی در سال منتشر می‌شود و همه نسخه‌های اصلی مسیر LTS خواهند داشت.

این تغییر فقط یک جابه‌جایی در تقویم نیست. تیمی که Runtime را در Dockerfile، CI، سامانه مانیتورینگ، Runbook امنیتی و قرارداد پشتیبانی مشتری ثبت کرده است باید فرض‌های قبلی خود را بازبینی کند. در این راهنما، خبر رسمی را به برنامه‌ای اجرایی تبدیل می‌کنیم تا بدون شتاب‌زدگی برای Alpha و بدون ماندن روی خط پایان‌عمر، مسیر ارتقا روشن باشد.

دقیقاً چه چیزی از اکتبر ۲۰۲۶ تغییر می‌کند؟

طبق اعلام رسمی چرخه جدید انتشار Node.js، از خط ۲۷ به بعد فقط یک نسخه اصلی در آوریل هر سال به وضعیت Current می‌رسد و همان نسخه در اکتبر وارد LTS می‌شود. مدل قدیمی دو انتشار اصلی در سال و تمایز فرد و زوج کنار گذاشته می‌شود.

• یک نسخه اصلی در سال، با انتشار Current در آوریل؛
• ارتقا به LTS در اکتبر همان سال؛
• Alpha از اکتبر تا مارس برای آزمایش زودهنگام؛
• امکان تغییرات semver-major در دوره Alpha؛
• ۳۰ ماه پشتیبانی LTS و در مجموع ۳۶ ماه از Current تا EOL؛
• هم‌راستایی شماره نسخه با سال انتشار Current؛ نسخه ۲۷ در سال ۲۰۲۷ Current می‌شود.

نکته ظریف این است که «پایان نسخه‌های فرد» عبارت دقیقی نیست. Node.js 27 یک نسخه فرد است و منتشر می‌شود؛ آنچه پایان می‌یابد، نقش قدیمی نسخه فرد به‌عنوان خط کوتاه‌عمر بدون LTS است.

چرا پروژه Node.js تقویم را عوض کرد؟

توضیح رسمی دو مسئله عملی را برجسته می‌کند. نخست، بیشتر سازمان‌ها نسخه‌های فرد را نادیده می‌گرفتند و تا LTS بعدی صبر می‌کردند. دوم، نگه‌داری هم‌زمان چهار یا پنج خط فعال، هزینه backport و انتشار امنیتی را برای جامعه‌ای که بخش بزرگی از آن داوطلب است بالا می‌برد.

کاهش تعداد خطوط فعال باید تمرکز نگه‌داران را بیشتر کند، اما برای مصرف‌کننده به معنی کاهش اهمیت نگه‌داری نیست. برعکس، حالا هر نسخه اصلی ارزش ارزیابی دارد و تیم نمی‌تواند با قاعده «نسخه فرد را رد کن» تصمیم بگیرد. معیار درست، وضعیت رسمی خط، سازگاری وابستگی‌ها و سطح ریسک سرویس است.

خط زمانی Node.js 26 و 27

Node.js 26؛ آخرین عضو مدل قبلی

Node.js 26 در آوریل ۲۰۲۶ با مدل قبلی Current شد. برنامه رسمی می‌گوید این خط در اکتبر ۲۰۲۶ وارد LTS، در اکتبر ۲۰۲۷ وارد Maintenance و در آوریل ۲۰۲۹ EOL می‌شود. بنابراین برای بسیاری از تیم‌هایی که در نیمه دوم ۲۰۲۶ ارتقا می‌دهند، ۲۶ پس از LTS شدن مقصد منطقی‌تری از Alpha بعدی است.

در زمان دسترسی به منابع، نسخه 26.8.1 با وضعیت Current در دسترس بود. شماره patch روزانه نباید در سند معماری ثابت شود؛ Pipeline باید از Registry معتبر نسخه دقیق را دریافت و Digest را قفل کند.

Node.js 27؛ نخستین عضو مدل جدید

Alpha نسخه ۲۷ در اکتبر ۲۰۲۶ آغاز می‌شود، نسخه 27.0.0 در آوریل ۲۰۲۷ به Current می‌رسد و در اکتبر ۲۰۲۷ LTS خواهد شد. دوره Alpha جایگزین مناسبی برای آزمایش پیش‌دستانه است، نه مقصد Production. در این دوره تغییرات ناسازگار عمدی ممکن است رخ دهد.

تیم کتابخانه، Framework یا ابزار Build باید زودتر از تیم محصول Alpha را آزمایش کند، چون هدف آن کشف شکست اکوسیستم است. سرویس درآمدزا یا مسیر احراز هویت باید تا رسیدن خط به مرحله مناسب سیاست سازمان صبر کند.

چه چیزهایی تغییر نمی‌کنند؟

اعلام رسمی می‌گوید مدت LTS تقریباً همان ۳۰ ماه می‌ماند، هم‌پوشانی میان خطوط LTS حفظ می‌شود و استانداردهای کیفیت، فرایند امنیتی و آزمون CITGM ادامه دارند. انتشار آوریل و ارتقای اکتبر نیز ریتم قابل‌پیش‌بینی می‌سازند.

پس لازم نیست Runbook را از صفر بنویسید. بخش‌هایی مانند Inventory، آزمون وابستگی Native، Canary، Rollback و رسیدگی به CVE همچنان معتبرند. آنچه باید اصلاح شود، فرض «زوج برابر LTS آینده» و دفعات برنامه‌ریزی نسخه اصلی است.

Alpha، Current، LTS و EOL را یکی ندانید

• Alpha: شش ماه آزمایش زودهنگام؛ تغییرات semver-major ممکن است و Production مقصد آن نیست.
• Current: شش ماه تثبیت پس از انتشار اصلی آوریل؛ برای تجربه قابلیت تازه و بازخورد مناسب‌تر است.
• LTS: خط پشتیبانی بلندمدت برای بارکاری Production که اصلاحات و نگه‌داری برنامه‌ریزی‌شده دریافت می‌کند.
• EOL: پایان پشتیبانی پروژه؛ خط نباید مبنای سرویس متصل به اینترنت باقی بماند.

صفحه وضعیت نسخه‌های Node.js مرجع روز انتخاب است. نوشته‌های قدیمی وبلاگ یا Tag قدیمی Docker ممکن است وضعیت امروز را منعکس نکنند؛ در Change Request باید لینک و تاریخ بررسی ثبت شود.

ماتریس انتخاب نسخه برای تیم‌ها

یک سیاست کوتاه می‌تواند اختلاف‌ها را کم کند:

• سرویس Production عمومی: آخرین Active LTS یا Maintenance LTS مورد تأیید سازمان، با patch به‌روز.
• سرویس داخلی کم‌ریسک: LTS پیش‌فرض؛ Current فقط با مالک مشخص، پایش و Rollback.
• کتابخانه یا CLI: آزمون Alpha و Current برای کشف ناسازگاری، همراه با پشتیبانی رسمی از خطوط LTS.
• محیط آموزشی و آزمایشگاه: Alpha برای آشنایی با تغییرات، بدون داده واقعی یا دسترسی Production.
• نسخه EOL: استثنای زمان‌دار با برنامه خروج، نه یک انتخاب عادی.

اگر تیم هنوز در ابتدای مسیر است، نقشه راه JavaScript باید مفهوم Runtime و نسخه پشتیبانی‌شده را جدا از خود زبان توضیح دهد. نوشتن JavaScript صحیح، به‌تنهایی امنیت Runtime قدیمی را حل نمی‌کند.

امنیت، دلیل اصلی برای مدیریت Lifecycle

اطلاعیه امنیتی ژوئیه ۲۰۲۶ Node.js اصلاحاتی با بالاترین شدت HIGH را برای خطوط فعال ۲۲، ۲۴ و ۲۶ منتشر کرد. دامنه موارد از HTTP/2 و Permission Model تا TLS، DNS، zlib و node:sqlite گسترده بود. پیام اجرایی این نیست که همه سرویس‌ها الزاماً آسیب‌پذیرند؛ پیام این است که خط فعال مسیر دریافت اصلاح دارد.

یک نسخه EOL ممکن است همان کد آسیب‌پذیر را داشته باشد، اما Patch رسمی دریافت نکند. بنابراین Inventory نسخه Node باید بخشی از مدیریت آسیب‌پذیری باشد. اسکن package-lock بدون دانستن نسخه Runtime، تصویر امنیتی کاملی نمی‌سازد.

Runbook نودروزه برای چرخه جدید

روز ۱ تا ۳۰: موجودی و تصمیم

1. نسخه Node همه سرویس‌ها، Jobها، Functionها و Imageهای پایه را استخراج کنید.
2. وضعیت هر خط را با مخزن رسمی Release Working Group تطبیق دهید.
3. وابستگی‌های Native، ABI-sensitive و ابزارهای Build را مشخص کنید.
4. مالک فنی، پنجره ارتقا و تاریخ EOL هر سرویس را ثبت کنید.

روز ۳۱ تا ۶۰: Build و آزمون موازی

1. یک Matrix CI برای LTS فعلی و مقصد بعدی بسازید.
2. Unit، Integration و End-to-End را روی هر دو Runtime اجرا کنید.
3. هشدارهای deprecation، مصرف حافظه، زمان Startup و Latency را مقایسه کنید.
4. Image مقصد را با نسخه دقیق و Digest قفل و SBOM تولید کنید.

روز ۶۱ تا ۹۰: Canary و تثبیت

1. در محیط Stage داده و ترافیک نماینده تولید کنید.
2. درصد کوچکی از ترافیک Production را به Canary بدهید.
3. Error Rate، Event Loop Lag، Memory، CPU و نرخ Timeout را بسنجید.
4. پس از عبور از گیت‌ها rollout را مرحله‌ای کامل و Runtime قبلی را از Registry داخلی خارج کنید.

Dockerfile و CI را چگونه اصلاح کنیم؟

استفاده از Tag مبهم مانند node:latest امکان تغییر ناگهانی Runtime را وارد Build می‌کند. در مقابل، قفل‌کردن همیشگی یک patch نیز Patch امنیتی را متوقف می‌کند. راه میانه این است که ارتقای Image با Pull Request خودکار پیشنهاد شود، Digest در هر Merge ثبت و تست‌ها پیش از پذیرش اجرا شوند.

در راهنمای Docker برای توسعه‌دهندگان اصل تکرارپذیری Build مهم است. برای Node.js این اصل را با چند کنترل کامل کنید: نمایش node --version در لاگ Build، بررسی معماری CPU، اجرای Smoke Test داخل Image نهایی و جلوگیری از Deploy خط EOL.

• نسخه Runtime را در Dockerfile، CI و محیط Cloud یکسان کنید.
• از Multi-stage build استفاده کنید، اما نسخه Stageها را هماهنگ نگه دارید.
• Addonهای Native را در همان ABI مقصد Build یا مجدداً نصب کنید.
• Health Check را فقط به بالا آمدن Process محدود نکنید؛ یک مسیر واقعی را بسنجید.

TypeScript و ابزارهای Build چه اثری می‌گیرند؟

تفکیک مطرح‌شده در مقایسه TypeScript و JavaScript اینجا هم کاربرد دارد. TypeScript ممکن است کد را برای Target مشخصی Emit کند، اما Runtime Node مسئول APIهای داخلی، ماژول‌ها، OpenSSL، V8 و رفتار Event Loop است. موفقیت Type Check ثابت نمی‌کند سرویس روی نسخه جدید یا قدیمی درست اجرا می‌شود.

در مهاجرت، نسخه TypeScript، tsconfig، تست‌رانر، bundler، loader و پکیج‌های ESM/CommonJS را کنار Runtime آزمایش کنید. تغییر هم‌زمان همه ابزارها علت خطا را مبهم می‌کند؛ بهتر است ارتقای Runtime Pull Request مستقل و قابل Rollback داشته باشد.

چطور از Alpha نسخه ۲۷ استفاده کنیم؟

Alpha برای سه گروه ارزش ویژه دارد: نگه‌داران کتابخانه، سازندگان ابزار Build و تیم‌هایی با وابستگی Native یا رفتار Runtime حساس. یک Workflow زمان‌بندی‌شده می‌تواند هفتگی تست‌ها را روی Alpha اجرا و نتیجه را غیرمسدودکننده گزارش کند.

قواعد ایمنی روشن باشند: هیچ Secret تولیدی، داده مشتری یا مسیر Deploy به Production در Job Alpha وجود نداشته باشد؛ شکست Alpha نباید انتشار LTS را متوقف کند؛ Issue باید حداقل نسخه Alpha، سیستم‌عامل، معماری و نمونه بازتولید داشته باشد. این کار بازخورد زودهنگام می‌دهد بدون آنکه ریسک آزمایش به کاربر منتقل شود.

پنج خطای رایج پس از تغییر تقویم

• گفتن «نسخه‌های فرد حذف شدند»: نسخه ۲۷ وجود دارد و LTS می‌شود؛ الگوی قدیمی حذف شده است.
• بردن Alpha به Production: Alpha برای پذیرش تغییر ناسازگار و کشف شکست است.
• ثابت‌کردن نسخه بدون Patch: تکرارپذیری نباید دریافت اصلاح امنیتی را متوقف کند.
• بررسی‌نکردن Imageهای پنهان: Job، Worker و ابزار Migration نیز Runtime دارند.
• ارتقای هم‌زمان Runtime و Framework: دامنه تغییر بزرگ، تشخیص Regression و Rollback را دشوار می‌کند.

چک‌لیست پیش از ارتقای Production

• خط مقصد در صفحه رسمی هنوز پشتیبانی می‌شود.
• نسخه دقیق و Digest Image ثبت شده است.
• همه وابستگی‌های Native دوباره Build و آزموده شده‌اند.
• Unit، Integration و E2E روی Runtime مقصد سبز هستند.
• هشدارهای deprecation بررسی و مالک‌گذاری شده‌اند.
• Latency، حافظه و Event Loop Lag با نسخه فعلی مقایسه شده‌اند.
• Canary، Alert و Rollback تمرین شده‌اند.
• Inventory و Runbook پس از rollout به‌روز شده‌اند.

جمع‌بندی

تقویم جدید Node.js تصمیم نسخه را ساده‌تر می‌کند: از خط ۲۷ هر نسخه اصلی مسیر LTS دارد و تنها یک انتشار اصلی در سال خواهیم داشت. در عوض، تیم‌ها باید عادت ذهنی فرد و زوج را کنار بگذارند و وضعیت Alpha، Current، LTS و EOL را مستقیماً از منابع رسمی بخوانند.

تا اکتبر ۲۰۲۶ کار درست، مهاجرت عجولانه به Alpha نیست. موجودی Runtimeها را کامل کنید، Node.js 26 را پس از رسیدن به مرحله مناسب سیاست خود ارزیابی کنید، Matrix CI بسازید و Alpha 27 را فقط در مسیر آزمایش ایزوله وارد کنید. امنیت و قابلیت بازگشت، معیار موفقیت ارتقا هستند؛ نه صرفاً جدیدبودن شماره نسخه.

اگر می‌خواهید نسخه Node.js، کانتینرها و Pipeline استقرار پروژه‌تان را بدون توقف سرویس برای چرخه جدید آماده کنید، برای یک ممیزی فنی و برنامه مهاجرت با خانه برنامه‌نویسان البرز در تماس باشید.