Yesterday, in https://etherpad.openstack.org/p/newton-oslo-backwards-compat-testing we actually reached consensus - well, 7/10 for and noone against - doing 1 cycle backwards compatibility in Oslo.
That means that after we release a thing, code using it must not break (due to an Oslo change) until a release from the cycle *after* the next cycle.. Concretely, add a thing at the start of L, we can break code using that exact API etc at the start of N. We could try to be clever and say 'Release of L, can break at the start of N', but 'release of L' is now much fuzzier than it used to be - particularly with independent releases of some things. So I'd rather have a really simple easy to define and grep for rule than try to optimise the window. Happy if someone else can come up with a way to optimise it. This is obviously not binding on any non-oslo projects: os-brick, python-neutronclient etc etc: though I believe folks in such projects are generally cautious as well. The key thing here is that we already have to do backwards compat to move folk off of a poor API onto a new one: all this policy says is that the grace period needs to cross release boundaries. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
