يعلم كثير من القراء أن عددًا غير معتاد من الميزات أُلغي من فرع PostgreSQL 19 بعد بدء فترة الإصدار التجريبي. ليس من غير المألوف إلغاء بعض الميزات، وربما يُتوقع إلغاء واحدة في كل دورة. لكن هذه المرة، وبحسب طريقة الحساب، أُلغي نحو 8 إلى 10 ميزات مهمة، وبعضها في مراحل متأخرة نسبيًا من فترة الإصدار التجريبي. يستعرض المؤلف، وهو مطور أو ملتزم في بعض الميزات المتأثرة، ما حدث، ويقدم آراء ما زالت أولية.
على الأرجح أن الأسباب مزيج من عوامل تختلف من ميزة إلى أخرى. يقر المؤلف بأن الكود ربما لم يكن جيدًا بما يكفي، وبأن الفريق ربما لم يقم بعمل كافٍ. وقد يكون الأمر محض صدفة: إذ كان المشروع في مرحلة نجاح، فحاول تنفيذ عدة ميزات تبين أنها أصعب من أن تُنجز في الوقت المحدد. وكان لبعض الميزات عيوب معمارية جوهرية يصعب إصلاحها بسرعة خلال فترة الإصدار التجريبي. وعانت ميزات أخرى من سلسلة طويلة من مشكلات الحالات الحدية غير الضارة نسبيًا، والتي كانت في الدورات السابقة ستظهر لاحقًا وتُعالج تدريجيًا على مدى السنوات التالية.
غيّرت مراجعة الكود المدعومة بنماذج اللغة الكبيرة هذا الجدول الزمني. فهذه المشكلات تُكتشف الآن بسرعة أكبر، مما يترك للمطورين قائمة من نحو أربعين تقرير خلل. وحتى لو احتاج كل منها إلى إصلاح صغير، فإن التكلفة الثابتة لمعالجة كل واحد منها تتراكم وينفد الوقت. وقد كُتبت معظم الميزات المتأثرة قبل أن تصبح أدوات المراجعة هذه مفيدة، لذلك ارتفع معيار الجودة الفعلي منذ إضافتها. ويرى المؤلف أن هذا ليس ناتجًا عن "البرمجة بالإحساس"، لأن الكود سابق لهذا الاحتمال.
وزاد الوضع سوءًا أزمة الأمان المعروفة باسم "Vulnpocalypse"، التي استدعت كثيرًا من كبار المطورين لإصلاحات الأمان من أبريل إلى أغسطس. ونتيجة لذلك قُلّصت المراجعة والاختبار الإضافيان المعتادان خلال الإصدار التجريبي، ولم يُستأنفا إلا لاحقًا، ما يفسر ظهور كثير من المشكلات متأخرًا. ويعتقد المؤلف أن شهرين إضافيين كانا سيكفيان لمعالجة كثير من المشكلات الأصغر، لكن المجتمع اختار الالتزام بجدول الإصدار بدلًا من التأجيل.
المصدر: Hacker News · لخّصه HeadlinesBriefing