I would argue that is not the case for a sufficiently large project (such as openshift-ansible). We hit quite a few problems when migrating from 1.9 to 2.0 and to a lesser extent 2.0 to 2.1. The 2.1 to 2.2 migration went smoothly (we had previously fixed the templating deprecation warnings, otherwise we would have been bit), but we've hit regressions with 2.2.1.
I agree that the Ansible team is very responsive to fixing issues, but the architecture changes from 1.9 to 2.x introduced breaking changes that affected playbook parsing and breaking plugins.
I agree, however there would need to be a transition period for projects that can't respond immediately for breakage related to an Ansible update (moving to using a locked version in a virtualenv) or have other extenuating circumstances (openshift-ansible for example has a callback plugin that provides a friendly error for Ansible < 2.2 or Ansible != 2.2.1.0, though it looks like we'll need to add a test for 2.2.1.1 now as well). That said, the OpenShift jobs already use a virtualenv.
--
Jason DeTiberus