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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
