We work in small teams on a few apps that all rely on one central API, which is also developed in-house. The team working on this API is composed entirely of senior developers.
With every rollout of substantial changes, all app teams are asked to do a full regression test and report problems (if any).
Common knowledge dictates that this is the ultimate situation to use API versioning; the app specifies on which version it relies, and it can then be updated whenever the need is there. Updates to the API should not break existing applications. This would also make rollouts easier and quicker.
The idea of API versioning has been brought up with said team before, however, only to be dismissed as 'Versioning will turn into a mess'. And I agree that API versioning isn't the solution to all problems, but I think it could substantially improve our release process.
To me, this sounds mostly like an architect decision; however, we don't have anyone in the architect role. Most parties involved (PU, QA) seem to not really see the benefits of API versioning either. This is ridiculous to me, as it's an industry standard way of working. It reminds me of people who use dropbox as a VCS.
What is the best way to push, within my means, and without making it seem as if I'm trying to do the other team's work?