It’s been a long couple of sprints, but your team has managed to pull together and complete the features promised for delivery. Your unit tests have passed, and you feel confident in rolling your changes out to production. However, there’s a last minute ask to fix a minor bug by updating one of your project dependencies. There’s no change to your code base, and everyone thinks it should be a low risk change, so it’s pulled in last minute. But as soon as the change is included, all the tests start failing, and chaos ensues. After a day of painful troubleshooting, it’s determined that the newer dependency broke backwards compatibility with your application, and your application stopped working as a result. Good version management could have helped you avoid this situation.
Software under active development evolves over time as bugs are fixed and new features are added. Simply releasing every change as soon as it's finished has a high potential of causing chaos. To help keep things simple, changes are usually bundled into a known good build and released together. However, since there are now multiple releases of the same piece of software, it becomes important to know what features and bugs are present in any given release. To distinguish these releases, software teams use various versioning schemes to tag their releases so they can easily communicate to their users what to expect in any given release.
Read More
