Одна мысль по этому поводу: временные шаблоны совместимости, подобные этому, могут быть безопаснее, если они имеют某种 механизм самовыключения или условия защиты, а не продолжают бесконечно переопределять зависимости Discourse.
Например, для временных бэкпортов исходного кода я планирую использовать хуки в production, которые сначала проверяют, присутствует ли уже исправление в upstream, и применяют патч только в том случае, если он всё ещё необходим.
В данном случае, что-то вроде следующего могло бы потенциально предотвратить продолжение использования закреплённой версии 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 теперь требует Aws::S3::TransferManager; пропускаем устаревшее понижение версии aws-sdk-s3 Backblaze"
else
echo "Применяем временный pin совместимости aws-sdk-s3 Backblaze"
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.