Look at my reply to the guy above you for a little more detail.
We _do_ actually test every every code change _before_ it enters a "devel" branch (everything flows through tested pull requests). Part of that testing is actually testing against _downstream_ applications (user's applications). Once it's deemed fit to go into "devel" the PR is merged and a new set of automated testing is kicked off... with more extensive testing against all downstream applications. If that passes then a "release" is automatically done by merging to our "stable" branch (which is actually master).
The entire system (other than pressing "Merge" on the PR) is completely automated... allowing us to roll out several releases per day that are guaranteed to work with all of our user's applications. This gives them the freedom to use the very most up to date version of the library (the master branch) without fear.
As for the version "number" it actually doesn't matter... no one talks about "I'm on version 4ce653b488b3f1a3f929caa136f63f7846303967"... the only question is: "Did you update today?"...
BTW: If we make an incompatible API change (which is rare). _WE_ actually put in PR's to all of our downstream user's applications (currently numbering in the hundreds) to fix their applications.
The purpose of all of this (which is talked about in the papers) is to keep the entire community running on the newest code... all the time. It trades support burden (of old versions) for a burden of always passing extremely rigorous tests. We've found it to be a really positive thing and our userbase is continuing to grow because of it.
About that userbase. This is massively-parallel, scientific and engineering software (the kind that runs on the largest supercomputers in the world). Several hundred users is actually pretty great