Open Stack

Excerpts from Tomas Sedovic's message of 2014-06-16 09:19:40 -0700:
> All,
> 
> After having proposed some changes[1][2] to tripleo-heat-templates[3],
> reviewers suggested adding a deprecation period for the merge.py script.
> 
> While TripleO is an official OpenStack program, none of the projects
> under its umbrella (including tripleo-heat-templates) have gone through
> incubation and integration nor have they been shipped with Icehouse.
> 
> So there is no implicit compatibility guarantee and I have not found
> anything about maintaining backwards compatibility neither on the
> TripleO wiki page[4], tripleo-heat-template's readme[5] or
> tripleo-incubator's readme[6].
> 
> The Release Management wiki page[7] suggests that we follow Semantic
> Versioning[8], under which prior to 1.0.0 (t-h-t is ) anything goes.
> According to that wiki, we are using a stronger guarantee where we do
> promise to bump the minor version on incompatible changes -- but this
> again suggests that we do not promise to maintain backwards
> compatibility -- just that we document whenever we break it.
> 

I think there are no guarantees, and no promises. I also think that we've
kept tripleo_heat_merge pretty narrow in surface area since making it
into a module, so I'm not concerned that it will be incredibly difficult
to keep those features alive for a while.

> According to Robert, there are now downstreams that have shipped things
> (with the implication that they don't expect things to change without a
> deprecation period) so there's clearly a disconnect here.
> 

I think it is more of a "we will cause them extra work" thing. If we
can make a best effort and deprecate for a few releases (as in, a few
releases of t-h-t, not OpenStack), they'll likely appreciate that. If
we can't do it without a lot of effort, we shouldn't bother.

> If we do promise backwards compatibility, we should document it
> somewhere and if we don't we should probably make that more visible,
> too, so people know what to expect.
> 
> I prefer the latter, because it will make the merge.py cleanup easier
> and every published bit of information I could find suggests that's our
> current stance anyway.
> 

This is more about good will than promising. If it is easy enough to
just keep the code around and have it complain to us if we accidentally
resurrect a feature, that should be enough. We could even introduce a
switch to the CLI like --strict that we can run in our gate and that
won't allow us to keep using deprecated features.

So I'd like to see us deprecate not because we have to, but because we
can do it with only a small amount of effort.