Open Stack

Chris Dent wrote:
> [...] 
> That could very well be fine, but we have evidence that:
> 
> * some projects don't yet use microversions in their APIs
> * some projects have no intention of using microversions or at least
>   have internal conflict about doing so
> * some projects would like to change things (irrespective of
>   microversions)
> 
> What do we do about that? That's what I think we could be working
> out here, and why I'm persisting in dragging this out. There's no
> point making rules that a significant portion of the populace have
> no interest in following.
> 
> So the options seem to be:
> 
> * codify the two rules above as the backbone for the
>   api-compatibility assertion tag and allow several projects to not
>   assert that, despite an overall OpenStack goal
> 
> * keep hashing things out for a bit longer until either we have
>   different rules so we have more projects liking the rules or we
>   justify the rules until we have more projects accepting them

We were discussing this in the context of an "assert" tag, not a goal.
Assert tags are primarily meant as a way to communicate information to
deployers or users. The one proposed here simply communicates that the
project will not ever break "API compatibility" (as you loosely defined
it, "any extant client code that works should continue working"), and
that it is therefore safe to write long-term code against that API. It
is comparable to the "follows-deprecation-policy" tag. And it is always
ok to allow projects to not assert tags they are not ready to assert.

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.

Yes, it might ultimately result in more projects adopting that
commitment, because it will make their project look better in the
project navigator. Personally I see that potential outcome as a good
thing -- they should just do it when they are ready to do it.

-- 
Thierry Carrez (ttx)