Open Stack

Excerpts from Duncan Thomas's message of 2014-06-16 09:41:49 -0700:
> On 16 June 2014 17:30, Jason Rist <jrist at redhat.com> wrote:
> > I'm going to have to agree with Tomas here.  There doesn't seem to be
> > any reasonable expectation of backwards compatibility for the reasons
> > he outlined, despite some downstream releases that may be impacted.
> 
> 
> Backward compatibility is a hard habit to get into, and easy to put
> off. If you're not making any guarantees now, when are you going to
> start making them? How much breakage can users expect? Without wanting
> to look entirely like a troll, should TripleO be dropped as an
> official until it can start making such guarantees? I think every
> other official OpenStack project has a stable API policy of some kind,
> even if they don't entirely match...
> 

I actually agree with the sentiment of your statement, which is "backward
compatibility matters."

However, there is one thing that is inaccurate in your statements:

TripleO is not a "project", it is a "program". These tools are products
of that program's mission which is to deploy OpenStack using itself as
much as possible. Where there are holes, we fill them with existing
tools or we write minimal tools such as the tripleo_heat_merge Heat
template pre-processor.

This particular tool is marked for death as soon as Heat grows the
appropriate capabilities to allow that. This tool never wants to
be integrated into the release. So it is a little hard to justify
bending over backwards for BC. But I don't think that is what anybody
is requesting.

We're not looking for this tool to remain super agile and grow, thus
making any existing code and interfaces a burden. So I think it is pretty
easy to just start marking features as deprecated and raising deprecation
warnings when they're used.