Open Stack

This was a good session lead by Robert to fully understand the
repercussions of not ensuring backward compatibility guidelines.

In layman's terms, an Oslo API change made in Mitaka (the last release)
must remain fully backward compatible throughout the entire Newton release
(the current release).
A great reason is for all other OpenStack projects that do/may use and
adopt any Oslo changes from Mitaka.
If Oslo DID NOT maintain backwards compatibility throughout the full length
of the next cycle, then projects that had either implemented or plan to
implement Mitaka Oslo features may then have failing gate tests during this
cycle causing rework.
Oslo needs to remain stable during an entire cycle to ensure projects can
work consistently with Oslo libraries.

Thanks to Angus Lees (Gus) who in true debate form took the side of nay to
validate the proposal and enable a clear discussion (in the second of last
session).

Ronald



On Fri, Apr 29, 2016 at 2:13 PM, Robert Collins <robertc at robertcollins.net>
wrote:

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160502/e1e81907/attachment.html>