[openstack-dev] [TripleO] Backwards compatibility policy for our projects

Clint Byrum clint at fewbar.com
Tue Jun 17 17:21:57 UTC 2014


Excerpts from Tomas Sedovic's message of 2014-06-17 04:56:24 -0700:
> 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 :-).
> 

Let's just leave the capability forever. We're not adding things to
merge.py or taking it in any new directions. Keeping the code does not
cost us anything. Some day merge.py won't be used, and then it will be
like we deleted the whole thing.



More information about the OpenStack-dev mailing list