كروم كل أسبوعين: ما الذي ينكسر في خطة اختبارك؟

منذ 2021 كان إيقاع كروم ثابتاً ومريحاً: نسخة كبرى كل أربعة أسابيع. كنت تعرف متى تنظر في ملاحظات الإصدار، ومتى تراجع ما سيُحذف، ومتى تشغّل مصفوفة الاختبار كاملة. هذا الإيقاع انتهى في 8 سبتمبر 2026 مع إطلاق كروم 153: النسخة الكبرى صارت تصل كل أسبوعين على الحاسب وأندرويد وiOS. وكروم 154 نزل بالفعل اليوم، 22 سبتمبر، تماماً على الموعد الجديد.

معظم التغطية تعاملت مع الخبر كتفصيلة تشغيلية تخصّ جوجل وحدها. عملياً، التغيير لا يمسّ جوجل بقدر ما يمسّ الفرق التي بنت عمليّاتها كلها — الاختبار، والتجارب الأصلية، وجدول دعم المتصفحات — على افتراض أن الشهر هو وحدة القياس.

ما تغيّر بالضبط (وما لم يتغيّر)

التغيير أضيق مما يبدو من العنوان، وهذا مهم:

• قناة Stable: نسخة كبرى كل أسبوعين بدل أربعة.
• قناة Beta: تتبع الإيقاع نفسه، أسبوعين.
• Dev وCanary: لم يتغيّر فيهما شيء إطلاقاً.
• Extended Stable: باقية كما هي على دورة ثمانية أسابيع، مع إصلاحات أمنية تُنقل إليها أسبوعياً.

بعبارة أخرى: عدد الميزات الواصلة سنوياً لم يتضاعف. ما تغيّر هو حجم كل دفعة. الدفعة صارت نصف حجمها السابق وتصل ضعف عدد المرات.

جوجل تسوّق هذا كمكسب أمني في المقام الأول، والحجّة منطقية: الفجوة بين لحظة نشر الإصلاح علناً ولحظة وصوله لجهاز المستخدم — ما يسمّيه الأمنيّون نافذة «الـN-day» — تنكمش. الثغرة المُصلَحة علناً هي ثغرة مكشوفة، وكل يوم انتظار إضافي هو يوم هدية للمهاجم.

لماذا الدفعة الأصغر ليست بالضرورة أسهل

المنطق المعلن هو أن الإصدارات الأصغر أقل إرباكاً وأسهل في تشخيص ما بعدها. هذا صحيح تماماً — من زاوية التشخيص. حين ينكسر شيء بعد تحديث يحمل ثلاثين تغييراً، تعرف أين تبحث؛ حين يحمل مئة، تبدأ رحلة تخمين.

لكن التشخيص ليس التكلفة الوحيدة. هناك تكلفة ثانية لا تتقلّص مع حجم الدفعة: التكلفة الثابتة لكل دورة. تشغيل مصفوفة الاختبار، مراجعة ملاحظات الإصدار، تحديث بيئة التطوير، إبلاغ الفريق، التحقّق من أن شيئاً لم ينكسر في المسارات الحرجة — هذه أعمال تكلّف تقريباً الشيء نفسه سواء كان الإصدار يحمل عشرة تغييرات أو مئة.

ضاعِف عدد الدورات ونصّف حجم كل واحدة، فيبقى مجموع التغييرات ثابتاً بينما يتضاعف مجموع التكاليف الثابتة. هنا بالضبط يسكن الألم الحقيقي في هذا التحوّل.

الفريق الذي كان يخصّص ساعتين شهرياً لمواكبة كروم سيجد نفسه أمام ساعتين كل أسبوعين — أي ضعف الوقت لنفس كمية التغيير. والفريق الذي كان يعتمد على مراجعة يدوية سيكتشف أن المراجعة اليدوية لم تعد قابلة للاستمرار أصلاً.

التجارب الأصلية: الفخّ الذي لا ينتبه له أحد

أخطر أثر عملي في هذا التحوّل لا علاقة له بالاختبار، بل بـالتجارب الأصلية (Origin Trials) — الآلية التي تتيح لك تجربة ميزة تحت التطوير في الإنتاج عبر رمز (Token) مربوط بنطاقك.

التجربة الأصلية لا تُقاس بالأيام، بل بعدد النسخ الكبرى. تجربة تمتدّ ستة إصدارات كانت تعني ما يقارب ستة أشهر من الراحة. الإصدارات نفسها الآن تعني ثلاثة أشهر.

إن كنت تعتمد على ميزة تحت تجربة أصلية في مسار إنتاجي حقيقي، فانتهاء التجربة يعني توقّف الميزة عن العمل لمستخدميك بلا أي تغيير من جهتك — نشرة إخبارية تُرسَل، ورمز ينتهي، وشيء ما يتعطّل في صمت. إن لم تكن قد راجعت تواريخ انتهاء رموزك منذ الإعلان، فهذه هي المهمة التي تستحقّ نصف ساعة اليوم لا الشهر القادم.

هل تنتقل إلى Extended Stable؟

السؤال الذي يطرحه كل مسؤول تقني الآن. الجواب يعتمد على طبيعة ما تبنيه:

وضعك	الخيار الأنسب	السبب
موقع أو تطبيق ويب عام	Stable العادية	جمهورك عليها أصلاً؛ اختبارك يجب أن يطابق ما يراه المستخدم
أجهزة مُدارة داخل شركة	Extended Stable	ثمانية أسابيع تعطي فريق تقنية المعلومات نافذة تخطيط حقيقية
منتج مضمّن يعتمد Chromium	Extended Stable	دورة التكامل والاختبار لديك أطول من أسبوعين بطبيعتها
تطبيق ويب داخلي لموظفين	حسب سياسة التحديث لديك	الاتّساق مع أجهزة الموظفين أهمّ من الأحدث

انتبه إلى مفارقة في السطر الأول: Extended Stable تبدو الخيار «الآمن»، لكنها تعني أنك تختبر على نسخة أقدم مما يشغّله جمهورك فعلاً. لو كان منتجك موقعاً عاماً، فهذا يحوّل الأمان الظاهري إلى فجوة حقيقية بين بيئة اختبارك وبيئة مستخدميك. جوجل نفسها تصف Stable ذات الأسبوعين بأنها الخيار الأكثر أماناً لعموم المستخدمين، وهي محقّة: التحديث الأسرع يعني تعرّضاً أقصر.

خمس خطوات عملية لهذا الأسبوع

1. افحص رموز التجارب الأصلية. اجمع كل رمز تستخدمه في الإنتاج، وسجّل تاريخ انتهائه الفعلي بالنسخ لا بالشهور. أي رمز ينتهي خلال ثلاثة أشهر يحتاج خطة بديلة الآن.
2. حوّل مراجعة ملاحظات الإصدار إلى تنبيه آلي. متابعة يدوية كل أسبوعين هي مهمة ستُنسى في الأسبوع الرابع. اربط تغذية إصدارات كروم بقناة فريقك.
3. افصل مصفوفة الاختبار إلى طبقتين. طبقة سريعة على المسارات الحرجة تعمل مع كل إصدار، وطبقة شاملة تعمل شهرياً أو عند تغيير كبير. محاولة تشغيل كل شيء كل أسبوعين ستدفعك لإيقاف كل شيء.
4. راجع سياسة دعم المتصفحات المكتوبة عندك. عبارة «نَدعم آخر نسختين من كروم» كانت تعني شهرين، وصارت تعني شهراً واحداً. إن كنت قد وعدت عملاءك بذلك في عقد أو وثيقة، فالعبارة تحتاج صياغة جديدة بالتواريخ لا بالنسخ.
5. ثبّت نسخة المتصفح في اختباراتك الآلية. الاختبار الذي يسحب «أحدث كروم» تلقائياً صار يتغيّر تحتك ضعف عدد المرات، وفشل اختبار سببه تحديث متصفح لا تغيير كود هو أسوأ أنواع الوقت الضائع.

ماذا في كروم 153 نفسه؟

بعيداً عن الإيقاع، النسخة التي بدأت هذا التحوّل حملت تغييرات تستحقّ الذكر: دعماً أصلياً لصوت IAMF المكاني ثلاثي الأبعاد، وتحسينات على حاويات التمرير أحادية المحور في CSS.

لكن أكثرها دلالة هو نقل محرّك تحليل XML الأساسي إلى Rust. هذا امتداد لاتجاه واضح في المتصفحات: إعادة كتابة المكوّنات التي تعالج مدخلات غير موثوقة بلغة آمنة على مستوى الذاكرة. محلّلات الصيغ — XML وصور وخطوط — كانت تاريخياً من أخصب مصادر الثغرات في المتصفحات، لأنها تقرأ بيانات يصنعها طرف مجهول بالكامل.

وهنا يتّضح الخيط الجامع: النقل إلى Rust يقلّل احتمال ظهور الثغرة، ودورة الأسبوعين تقلّل عمر الثغرة بعد ظهورها. القرارَان يخدمان الهدف نفسه من طرفين مختلفين.

أسئلة شائعة

هل سيزيد هذا من أعطال موقعي؟

ليس بالضرورة. مجموع التغييرات السنوية لم يزد، وكل إصدار صار يحمل تغييراً أقل. لكن تواتر احتمال العطل يرتفع، ونافذة اكتشافك للعطل تضيق. الفرق الذي يعتمد على اختبار آلي جيّد لن يشعر بفرق كبير؛ الفريق الذي يعتمد على فحص يدوي دوري هو من سيدفع الثمن.

هل يعني هذا أن الميزات الجديدة ستصل أسرع؟

نعم، لكن بهامش محدود. الميزة التي كانت تنتظر بدء الدورة التالية قد تنتظر أسبوعين بدل أربعة. لا يعني ذلك أن جوجل تبني ميزات بوتيرة مضاعفة — بل أن الميزة الجاهزة لا تجلس في الرفّ منتظرة موعداً بعيداً.

هل ستتبع بقية المتصفحات الإيقاع نفسه؟

لم يُعلَن ذلك. لكن المتصفحات المبنية على Chromium ترث جدول Chromium بطبيعتها مع فارق زمني للتكامل، وهذا يجعل السؤال الأهم بالنسبة لك هو: هل اختبارك مرتبط بـ«كروم» أم بـ«محرّك Chromium»؟ الإجابة تحدّد كم من هذا التحوّل يخصّك فعلاً.

الخلاصة

الانتقال إلى إصدار كل أسبوعين ليس خبراً عن جوجل، بل اختبار لمدى أتمتة عمليّاتك. الفريق الذي يملك اختباراً آلياً حقيقياً وتنبيهات مرتبطة بتغذية الإصدارات لن يلاحظ التغيير تقريباً. الفريق الذي كان يعتمد على شخص يفتح ملاحظات الإصدار مرة في الشهر سيكتشف أن تلك الطريقة لم تعد تعمل.

الأولوية العملية الآن واحدة وواضحة: راجع رموز تجاربك الأصلية اليوم. باقي التغييرات تمنحك وقتاً للتكيّف؛ الرمز المنتهي لا يمنحك شيئاً، فقط يتوقّف.