فكرة واحدة من هذا: قد تكون قوالب التوافق المؤقتة مثل هذه أكثر أمانًا إذا كانت تحتوي على نوع من الشروط الذاتية الانتهاء أو الحماية، بدلاً من الاستمرار في تجاوز تبعيات Discourse بشكل غير محدود.
على سبيل المثال، مع عمليات الاستيراد المؤقتة للمصدر، أخطط لاستخدام الخطافات (hooks) في بيئة الإنتاج التي تتحقق أولاً مما إذا كان الإصلاح الموجود في المصدر الأصلي (upstream) موجودًا بالفعل، وتطبق الرقعة (patch) فقط إذا كانت لا تزال مطلوبة.
في هذه الحالة، كان من الممكن أن يمنع شيء على هذا الخط استمرار تثبيت aws-sdk-s3 1.177.0 القديم بمجرد أن بدأ Discourse نفسه في الاعتماد على وظائف SDK الأحدث:
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- |
if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
echo "Discourse now requires Aws::S3::TransferManager; skipping obsolete Backblaze aws-sdk-s3 downgrade"
else
echo "Applying temporary Backblaze aws-sdk-s3 compatibility pin"
bundle config set frozen false
sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
bundle update aws-sdk-s3
bundle add aws-sdk-core --version 3.215
fi
إن تلك الفحصية المحددة مجرد مثال توضيحي - من المرجح أن يكون فحص إصدارات أكثر عمومية أو فشلًا صريحًا عند تجاوز Discourse للإصدار المتوقع من SDK أفضل.
حتى الفشل بصوت عالٍ سيكون على الأرجح تفضيليًا على إنتاج حاوية بصمت حيث لم تعد جوهاتها (gems) تطابق الإصدارات التي يتوقعها Discourse.