On 16/06/14 18:51, Clint Byrum wrote: > 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.
Oh. I did assume we were talking about OpenStack releases, not t-h-t, sorry. I have nothing against making a new tht release that deprecates the features we're no longer using and dropping them for good in a later release. What do you suggest would be a reasonable waiting period? Say a month or so? I think it would be good if we could remove all the deprecated stuff before we start porting our templates to HOT. > >> 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. Right, that's fair enough. I've thought about adding a strict switch, too, but I'd like to start removing code from merge.py, not adding more :-). > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
