SDKバージョンを上げる時メンテナンスのリソースを十分に割けていないアプリでは、依存するパッケージの更新が2バージョン以上のメジャーアップデートになることもしばしばです。パッケージをアップデートすることで、ビルドが失敗するようになることもあります。一気にバージョンアップできると気楽ですが、そうではないことがほとんどです。今回は、依存パッケージの更新をする時に考えていることを、まとめてみます。状況によって対応は変わりますが、普段考えていることをまとめてみます。#何を最優先にするかにもよりますが、安全に対応することを考えていることが多いです。テストが実装されていればそれを活用しますが、案件によっては無いことも少なくありません。そのため、テストがない場合や、5バージョンのメジャーアップや5年分のバージョンアップのような場合、バージョンアップで変更する規模が大きい場合は、1バージョンずつリリースするなど、段階的な対応を行うようにします。#アプリで使用している依存パッケージの最新バージョンを確認します。合わせて、今使用しているバージョンが何ヶ月、何年前のものなのか、何世代前のものなのかを、GitHubなどのリポジトリや公式ドキュメントで確認します。このとき、リリースノートやマイグレーションガイドも見つけておくと、作業がスムーズです。#思い切って最新のバージョンに変更してビルドしてみます。ビルドの結果で、次のアクションが変わってきます。#ユニットテストがあれば実行し、十分に動作を確認します。動作中のログをよく確認し、警告やエラーが出ていないか確認します。APIの設計が変化していなくても、実際には挙動が変わっていることがあるので、動作確認やログのチェックを注意して行います。問題が発生したり、気になるログがある場合は、それについて調査します。リリースノートやパッケージのコード差分を読む場合もあります。#エラーの内容を読んで、すぐに修正できそうなら直します。エラーの内容によっては、バージョンをひとつずつ変えながらビルドが失敗するバージョンを把握することを選択します(ほとんどの場合はこっち)。#最新にしてビルドが失敗することを確認できたら、つぎは、どのバージョンでビルドが失敗するようになるかを確認します。バージョンが特定できれば良いので、状況に応じて臨機応変に行います。...メジャーやマイナーを変化させる時は、X.0.0やX.X.0のようなファーストリリースではなく、ラストバージョンを使うようにしている明らかに破壊的変更が入っていると思われる場合は、ビルドが成功することを確認しながら、段階的にバージョンを上げていくことを選択します。#失敗するバージョンが特定できたら、エラーログ・リリースノート・マイグレーションガイドをもとに、変更内容を確認して対応します。対応する時は、破壊的な変更が入ったバージョンの直前のバージョンで正しくビルドできることを確認した上で、変更が入ったバージョンに切り替えて本対応します。#SDKバージョンを引き上げる時(AndroidのtargetSdkVersionや、iOSで言うXcodeのバージョンを引き上げる時)は、言語・SDK・依存パッケージのバージョンを、SDKのリリース日に近いバージョンに合わせながらSDKのバージョンを上げていくことがあります。SDKが想定する最新の開発環境に合わせる意図があります。