Open Stack

On Wed, 25 Jan 2017, Thierry Carrez wrote:

> We were discussing this in the context of an "assert" tag, not a goal.

Yes, but it is often the case that changes are being evaluated as if
it was a goal. A couple of glance related changes experienced
reactions of "this doesn't meet compatibility guidelines":

     https://review.openstack.org/#/c/420038/
     https://review.openstack.org/#/c/414261/

This is perhaps a proper reaction as a sanity check, but if a
project does not subscribe to the mooted assert tag then whether it
is a blocker or not should be up to the project?

> I think that's a good commitment to document, and knowing which projects
> actually commit to that is very useful to our users (the appdev
> variety). I don't think that means every project needs to commit to that
> right now, or that microversions are the only way to make sure you won't
> ever break API compatibility. I just think it's a good information bit
> to communicate.

It is definitely a good commitment to document, but we need to make
sure that we express it is an optional commitment, if in fact it is.
I get the impression that a lot people think it is not.

And if the commitment is being made, then we need to make sure we
document what demarcates change boundaries (when they inevitably
happen) and how to manage them.

I think we would be doing a huge disservice to our efforts at making
the APIs consistent (amongst the different services) if we have
multiple ways to manage them.

BTW: I think we should start using the term "stability" not
"compatibility".

-- 
Chris Dent                 ¯\_(ツ)_/¯           https://anticdent.org/
freenode: cdent                                         tw: @anticdent