Open Stack

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