Hi,
While I understand Andrey and others and fully agree with them on the necessity and value of project respecting API rules and process for that -while I am one of the "worst citizen" on that matter in practice-, I think any proposal that involves enforcing developers to use or setup anything specific beyond the obvious is likely to fail. We cultivate diversity in the project and the community, and by this, we also cultivate "deviation" which ultimately drives to innovation which is something we're seeking.
So to me, enforcing a process to developers is 1. unrealistic because there will always be deviant people that we still want to feel welcome as they provide value and 2. not really desired as we want to constantly "lower the entry barrier" or "reduce maintenance effort" and such heavy process can really be expensive or blockers.
I also have the impression that this story is an instance of the agile's "People over process and tools" motto. Proposals that involve people to do thing differently are "process over people", proposals that enforce people to use a tools are "tools over people". Both should be avoided as final solution.
We see our community of contributors and committers very happy with Gerrit, good discussions happening here, people enjoy the review flow and the automated CI builds. So that's where people are and want to be when it comes to interacting and ensuring quality gates. This is where we should try to hook things; and since CI is just an instance of a build, it seems like putting some focus on automation of check at submission-time is something that would both reduce the need to follow a process and reduce the enforcement of tools. That is IMO the silver-bullet and where all consideration and effort on the topic of API versioning automation should be put. Let's continue the technical discussion about this silver-bullet in the related bugs ;)
