Open Stack

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 <rbtcollins at hpe.com>
Distinguished Technologist
HP Converged Cloud