ライブラリのバージョンアップ 必要な理由とタイミング

# 目次
1. バージョンアップが必要な理由
2. バージョンアップのタイミング

# 1. バージョンアップが必要な理由
- バグ、セキュリティリスク、機能の拡張の為
- バージョンアップする必要が来た時に蓄積された変更が多すぎると検証に工数がかかる為

[When to upgrade libraries](https://stackoverflow.com/questions/543680/when-to-upgrade-libraries#:~:text=Upgrading%20does%20make%20it%20easier,as%20well%20do%20that%20proactively.)
>Update: I understand Philuminati's point about not upgrading until you have a reason. However, I think of it this way: I continuously pursue improvements in my own code and I use libraries built by people that I believe think the same way. Would I fail to use my own improved code? Well, no. So why would I fail to use the code that others have improved?

[When would you choose *not* to update a third-party library to a newer version?](https://softwareengineering.stackexchange.com/questions/225217/when-would-you-choose-not-to-update-a-third-party-library-to-a-newer-version)

>If you never upgrade, over time you are stuck on an outdated version and will find bugs in your system that results from bugs in the library that have been fixed in later versions.

>Note that if you delay upgrade a long time "because so far none of the fixes matter to me", then when you do upgrade you may find it much harder due to accumulated impact.

[Library Updating. Risk it Now, or Risk it Later?](https://avandeursen.com/2012/11/11/library-updating-risk-it-now-or-risk-it-later/)
>There likely will come a moment in which upgrading must be done: To fix bugs, to improve security, or when the system’s functionality needs to be extended.
The longer you postpone updating, the bigger the eventual pain. As your system grows and evolves, the costs and risks of upgrading an old library increase. Such an accumulation of maintenance debt may lead to a much larger effort than in the case of smaller incremental updates.
In short, not upgrading your libraries immediately is taking the bet that it never needs to be done. Upgrading now is taking the bet it must be done anyway, in which case doing it as soon as possible is the cheapest route.

# 2. バージョンアップのタイミング
- 安定版までまめにバージョンアップする
- 機能の修正とは分けてリリースする
- 検証した上でリリースする

[When would you choose *not* to update a third-party library to a newer version?](https://softwareengineering.stackexchange.com/questions/225217/when-would-you-choose-not-to-update-a-third-party-library-to-a-newer-version)

>In my experience, the better approach is to default to sticking with the version you have. Presumably, your team has already tested the version you use and how it integrates with your system. If not, then your clients have.
Sure, when a new version comes out, your team should see if it addresses any bugs you have encountered, provides features you could take advantage of, or improves overall performance. Only after running it through testing again should you actually start using it.

[Why and when to Update Software API & Library](https://www.linkedin.com/pulse/why-when-update-software-api-library-goutham-nithyananda/)

>You always don't need to be in the latest versions. Better to be in the stable versions which are tested verified and widely used.

## 参考になる記事を書いてくださった皆様ありがとうございました！

# 宣伝させてください！
https://recruit.iimon.co.jp/