Excerpts from Duncan Thomas's message of 2014-06-16 09:41:49 -0700: > On 16 June 2014 17:30, Jason Rist <[email protected]> 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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
