Oh yeah those are fun. Ive come across projects just 6 months after creation that cant work if they have a small version update. So it just sits there for a LONG time before a senior dev (mostly me) decides to get grumpy and fix the dang thing.
CI/CD builds can help…but you have to have someone keep an eye out for potential issues and, in best case, have a development deploy actually test the dang things.
I had success running unit tests for software deployments in pairs, one with pinned versions (error on a failed build) and one unpinned (warning on a failed build)
so at least you get forewarning when an upstream dependency messes everything up, and if the software changes are somewhat regular than each log of pipeline runs should show incremental changes making it easier to spot the package that started breaking everything
And the discussion on whether or not to pin versions.
Pinned, these packages work together, but don’t automatically pull in security updates.
Don’t pin, things randomly change on each build, best of luck debugging things.
Oh yeah those are fun. Ive come across projects just 6 months after creation that cant work if they have a small version update. So it just sits there for a LONG time before a senior dev (mostly me) decides to get grumpy and fix the dang thing.
CI/CD builds can help…but you have to have someone keep an eye out for potential issues and, in best case, have a development deploy actually test the dang things.
I had success running unit tests for software deployments in pairs, one with pinned versions (error on a failed build) and one unpinned (warning on a failed build)
so at least you get forewarning when an upstream dependency messes everything up, and if the software changes are somewhat regular than each log of pipeline runs should show incremental changes making it easier to spot the package that started breaking everything
Pin API / ABI versions.
If you’re able to track that…