ما يحلّ بين نوفمبر 2026 ونهاية 2027
تُحدِّد ثمانية مواعيد روزنامة مجموعة مواقع العملاء. اثنان منها فاتا بالفعل: Node.js 20 (30 أبريل 2026) وDebian 11 LTS (31 أغسطس 2026). لم يعد يُخطَّط لهما، بل يُستدرَكان. أربعة تحلّ خلال اثني عشر شهرًا: PostgreSQL 14 وPHP 8.2 وNode.js 22 وUbuntu 22.04. واثنان يختمان 2027: PostgreSQL 15 وPHP 8.3.
يرتّبها الجدول التالي بحسب التاريخ، مع المصدر الأصلي والإجراء الواجب إدراجه في الخطة. قاعدة قراءة: التاريخ هو ما ينشره المطوّر، باليوم الدقيق حين يذكره، وبالشهر حين لا ينشر سواه. لا شيء هنا مأخوذ من موقع طرف ثالث دون تأكيد من المصدر. أما تفاصيل أي ترحيل فاتّبعوا الدليل المذكور في العمود الأول: هذه المقالة ترتّب ولا تعيد كتابة الدروس.
جدول نهاية الدعم بحسب التاريخ
مرّر الجدول أفقيًا
| المكوّن والدليل التفصيلي | نهاية الدعم والمصدر | الإجراء المطلوب جدولته |
|---|---|---|
| Node.js 20 — الدليل: نهاية عمر Node.js 20 وترحيل خادمكم الافتراضي | 30 أبريل 2026، فات موعده — مستودع nodejs/Release، ملف schedule.json | دَين تقني: الانتقال إلى Node.js 22 أو 24 دون انتظار |
| Debian 11 — الدليل: نهاية عمر Debian 11، وPlesk، وdist-upgrade أو الترحيل | 31 أغسطس 2026، فات موعده — wiki.debian.org/LTS | دَين تقني: dist-upgrade إلى Debian 13 أو الترحيل |
| PostgreSQL 14 — الدليل: نهاية عمر PostgreSQL وتخطيط رفع الإصدار | 12 نوفمبر 2026، آخر إصدار — postgresql.org/support/versioning | تفريغ واستعادة أو pg_upgrade إلى إصدار رئيسي مدعوم |
| PHP 8.2 — الدليل: نهاية عمر PHP 8.2 وقائمة الترحيل | 31 ديسمبر 2026، دعم الأمان — php.net/supported-versions | نقل كل المواقع إلى PHP 8.4، لأن PHP 8.3 ينتهي بعد عام |
| Node.js 22 | 30 أبريل 2027 — مستودع nodejs/Release، ملف schedule.json | الانتقال إلى Node.js 24 المدعوم حتى 30 أبريل 2028 |
| Ubuntu 22.04 LTS — الإجراء: Ubuntu 24.04 إلى 26.04 وdo-release-upgrade | مايو 2027، صيانة الأمان القياسية — ubuntu.com/about/release-cycle | الترقية إلى Ubuntu 24.04 قبل بداية الشهر |
| PostgreSQL 15 | 11 نوفمبر 2027، آخر إصدار — postgresql.org/support/versioning | التخطيط للإصدار الرئيسي التالي، وPostgreSQL 16 مدعوم حتى 9 نوفمبر 2028 |
| PHP 8.3 | 31 ديسمبر 2027، دعم الأمان — php.net/supported-versions | لا شيء يُفعل للمواقع التي على PHP 8.4 أصلًا (دعم الأمان حتى 31 ديسمبر 2028) |
الدعم النشط ودعم الأمان وآخر إصدار: ثلاثة معانٍ لكلمة النهاية
لا يقصد المطوّرون جميعًا المعنى نفسه بالنهاية. يميّز PHP بين مرحلتين: الدعم النشط الذي يقدّم إصلاحات الأخطاء والأمان، ثم دعم الأمان الذي لا يوفّر سوى الإصلاحات الحرجة. خرج PHP 8.2 من الدعم النشط في 31 ديسمبر 2024، وPHP 8.3 في 31 ديسمبر 2025. فتواريخ الجدول هي إذن تواريخ دعم الأمان: 31 ديسمبر 2026 لـ PHP 8.2، و31 ديسمبر 2027 لـ PHP 8.3. ويبقى PHP 8.4 في الدعم النشط حتى 31 ديسمبر 2026 وفي دعم الأمان حتى 31 ديسمبر 2028.
يتحدث PostgreSQL عن آخر إصدار: بعد التاريخ لا يصدر أي إصدار فرعي آخر لذلك الإصدار الرئيسي. ويتحدث Node.js عن نهاية عمر الفرع، وDebian وUbuntu عن نهاية صيانة الأمان القياسية. وفي كل الحالات، بعد التاريخ لا يعود الدعم القياسي للمطوّر يصلح ثغرة مكتشفة: هذا التاريخ، لا توقف الموقع، هو ما يحدّد الخطر.
كيف يُرتَّب الأسطول: ست قواعد أولوية
- الديون أولًا — تجاوز Node.js 20 وDebian 11 تاريخ نهايتهما؛ فيسبقان أي موعد قادم، حتى لو لم يُظهر الموقع أي عرَض.
- ثم التاريخ الأقرب — ترتيب الجدول هو ترتيب العمل، ما لم يفرض العميل قيدًا مخالفًا.
- الورشة الأطول قبل الأقصر — الإصدار الرئيسي من PostgreSQL يتطلب استعادة مجرَّبة؛ أما تغيير إصدار PHP فيُتحقَّق منه موقعًا بموقع. فتُطلَق الأولى مبكرًا.
- النظام يحمل الباقي — غالبًا ما يحدّد إصدار Debian أو Ubuntu إصدارات PHP وقواعد البيانات في مستودعاته؛ فتُخطَّط ترقية النظام معها.
- العميل ذو المواعيد المتعددة أولًا — موقع يجمع PHP 8.2 وNode.js 20 وPostgreSQL 14 يكلّف ثلاثة تدخلات إن عولج مكوّنًا مكوّنًا، وتدخلًا واحدًا إن عولج بنافذة.
- التاريخ غير المؤكد يُعامَل من بدايته — حين لا ينشر المطوّر سوى الشهر، يُخطَّط قبل الشهر لا في آخر يوم منه.
الديون المستحقة فعلًا: Node.js 20 وDebian 11
سطران في الجدول لم يعودا توقعات. بلغ Node.js 20 نهايته في 30 أبريل 2026، وبلغ Debian 11 نهاية دعم LTS في 31 أغسطس 2026. الخطأ المعتاد أن يُدرجا في ميزانية السنة التالية وهما أصلًا خارج الدعم. الدَّين يُقدَّر ويُسدَّد؛ ولا يُخطَّط بإيقاع نهاية عمر مستقبلية.
بالنسبة إلى Node.js، الهدف هو الفرع 22 أو الفرع 24. ينتهي الفرع 22 في 30 أبريل 2027 والفرع 24 في 30 أبريل 2028: واختيار الفرع 24 يجنّبكم العودة إلى الورشة نفسها بعد ستة أشهر. وبالنسبة إلى Debian، الهدف هو Debian 13 الذي ينتهي دعم LTS له في 30 يونيو 2030. أما Debian 12 فمجرد محطة: يمتد دعم LTS له من 11 يونيو 2026 إلى 30 يونيو 2028. الإجراءات الكاملة في أدلتنا عن Node.js 20 وعن Debian 11، ولا نعيدها هنا.
PostgreSQL: الموعد الذي لا يُستدرَك في المكان نفسه
ينشر PostgreSQL 14 آخر إصدار له في 12 نوفمبر 2026، وPostgreSQL 15 في 11 نوفمبر 2027، وPostgreSQL 16 في 9 نوفمبر 2028. الإيقاع سنوي، وهي العائلة الوحيدة في الجدول التي لا يكون تغيير الإصدار فيها مجرد تحديث: فالإصدار الرئيسي لا يُثبَّت فوق سابقه، لأن صيغة التخزين تتغير من إصدار رئيسي إلى آخر.
يبقى طريقان: نسخة منطقية تُستعاد في الإصدار الجديد (pg_dump ثم pg_restore)، أو pg_upgrade الذي يحوّل مجلد البيانات. وفي الحالتين، احسبوا توقفًا يتناسب مع حجم القاعدة، واستعادة مجرَّبة قبل التحويل. وبالنسبة إلى أسطول المواقع، يضع هذا PostgreSQL في مقدمة الطابور متى اقترب تاريخه، ولو كان الموقع الذي يستخدمه بسيطًا. تفاصيل الطريقتين في دليلنا عن رفع إصدار PostgreSQL.
MySQL: غياب مقصود عن الجدول
لا يظهر MySQL في الجدول، وهذا مقصود. يتداول موقع endoflife.date تاريخًا لنهاية MySQL 8.0، لكننا لم نجده في توثيق Oracle الذي قرأناه: وبلا مصدر أصلي يبقى خارج الجدول. الثابت هو نموذج سلاسل LTS: خمس سنوات من الدعم الأساسي، وثلاث سنوات من الدعم الموسَّع، وانتقال من LTS إلى LTS دون تجاوز أي سلسلة. وMySQL 8.4 سلسلة LTS. وإن كان بعض العملاء ما زالوا على 8.0، فدليل الترحيل إلى MySQL 8.4 يبقى المرجع؛ أضيفوا السطر إلى الجدول متى قرأتم التاريخ لدى المطوّر.
التجميع حسب العميل وحسب النافذة: الطريقة في سبع خطوات
قراءة إصدارات كل خادم لدى العميل
على Debian أو Ubuntu:
lsb_release -d. على RHEL أو AlmaLinux:cat /etc/os-release. ثم لكل حزمة:php -vوnode -vوpsql --version. سطر لكل خادم ولكل مكوّن في جدول بيانات.عدم نسيان الحاويات
قد يستضيف خادم محدَّث صورة قديمة. اعرضوها بالأمر
docker image ls، ثم استجوبوا كل صورة:docker run --rm <image> php -vأوdocker run --rm <image> node -v.وضع تاريخ النهاية على كل سطر
انقلوا تاريخ جدول هذه المقالة بجانب كل مكوّن رصدتموه. العمود الناتج هو الوحيد الذي تحتاجونه للفرز.
حساب أول موعد لكل عميل
لكل عميل، احتفظوا بأقرب تاريخ عبر جميع الخوادم. يحدّد هذا نافذة العميل: وكل ما ينتهي في الأشهر التالية ينضم إلى التدخل نفسه.
اختيار نافذة واحدة لكل عميل
PHP وNode.js والنظام في تدخل واحد، بنسخة احتياطية مسبقة واحدة وخطة رجوع واحدة. ويقترح جدول النوافذ أدناه تقسيمًا بحسب المواعيد.
التجربة على نسخة قبل لمس الإنتاج
استعيدوا النسخة الاحتياطية على جهاز اختبار، ونفّذوا الترقية، ثم افحصوا الموقع. وفي PostgreSQL، استعيدوا التفريغ وشغّلوا استعلامات التطبيق قبل التحويل.
التدوين وإعادة الحساب
بعد كل تدخل، حدّثوا السطر بالإصدار الجديد وتاريخ نهايته. يُعاد حساب الجدول تلقائيًا، ويصبح جدول البيانات سجل الوكالة.
نوافذ التدخل المقترحة
مرّر الجدول أفقيًا
| النافذة | المواعيد المغطاة | التجميع الموصى به |
|---|---|---|
| النافذة 1: قبل 12 نوفمبر 2026 | PostgreSQL 14 وحده | ترقية PostgreSQL وحدها تتسع لهذه الأيام الخمسة عشر؛ أما دَينا Node.js 20 وDebian 11 فيُعالجان بالتوازي دون انتظار هذا التاريخ |
| النافذة 2: قبل 31 ديسمبر 2026 | PHP 8.2 | نقل كل المواقع مباشرة إلى PHP 8.4 لتفادي ورشة ثانية خلال السنة، في نافذة تُحدَّد قبل فترة تجميد نهاية السنة |
| النافذة 3: قبل شهرين من 30 أبريل 2027 | Node.js 22 وUbuntu 22.04 (مايو 2027) | تدخل واحد: بيئة التشغيل والنظام، تُحدَّد قبل شهرين من أول تاريخ: فانتظار 30 أبريل 2027 لا يترك أي هامش |
| النافذة 4: قبل 11 نوفمبر 2027 | PostgreSQL 15 | الإصدار الرئيسي التالي بالتفريغ والاستعادة أو pg_upgrade، بعد تجربة على نسخة |
| النافذة 5: قبل 31 ديسمبر 2027 | PHP 8.3 | لا تخص إلا المواقع التي بقيت على PHP 8.3 لتنتقل إلى PHP 8.4؛ ويمكن دمجها مع النافذة 4 لدى العملاء الذين يجمعون الاثنين |
Ubuntu 22.04: لماذا «مايو 2027» بلا يوم
بالنسبة إلى Ubuntu 22.04 LTS، تعلن Canonical نهاية صيانة الأمان القياسية في مايو 2027 دون نشر يوم. ويعرض موقع endoflife.date تاريخ 1 يونيو 2027. القراءتان متوافقتان مع نهاية الشهر، لكن صياغة Canonical وحدها مصدر أصلي؛ أما يوم الموقع الآخر فقراءة. لذلك نكتب «مايو 2027» ونخطّط للترقية قبل بداية الشهر.
والإصدار التالي، Ubuntu 24.04 LTS، معلن بصيانة قياسية حتى مايو 2029. وإجراء do-release-upgrade موصوف في دليلنا Ubuntu 24.04 إلى 26.04؛ وينطبق بالطريقة نفسها من LTS إلى التي تليها، مع نسخة احتياطية كاملة قبل كل قفزة.
الجدول يُقرَّر ولا يُفوَّض
تواريخ هذه المقالة هي تواريخ وقت كتابتها: أعيدوا التحقق منها لدى المصدر قبل التخطيط، فقد يعدّلها المطوّر. توفّر ServOrbit الأدلة؛ أما إدارة خوادمكم وقيادة الترحيلات فتبقى من مسؤوليتكم، دليل مقدَّم دون تكفّل بالتنفيذ. جرّبوا دائمًا على نسخة.
رؤية الأسطول كله في جدول واحد
لا قيمة لجدول نهاية الدعم إلا إذا رأيتم الأسطول كله في مكان واحد. تجمع منصة الوكالات من ServOrbit.com نطاقات عملائكم واستضافاتهم وخوادمهم الافتراضية مع مواعيد تجديدها: وهي نقطة انطلاق الخطوة 1، قائمة محدَّثة بالعملاء والأجهزة بدل جدول بيانات يُعاد بناؤه كل فصل. أما مواعيد نهاية دعم البرمجيات فلا تتابعها المنصة: تُقرأ الإصدارات المثبَّتة على كل خادم على الأجهزة بالأوامر أعلاه، وتُقابَل بهذا الجدول.
التوثيق الرسمي
إصدارات PHP المدعومة: https://www.php.net/supported-versions.php
سياسة إصدارات PostgreSQL: https://www.postgresql.org/support/versioning/
جدول إصدارات Node.js: https://github.com/nodejs/Release/blob/main/schedule.json
Debian LTS: https://wiki.debian.org/LTS
دورة إصدارات Ubuntu: https://ubuntu.com/about/release-cycle
إصدارات MySQL وسلاسل LTS: https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html
تواريخ Ubuntu في endoflife.date: https://endoflife.date/ubuntu
