<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 8 July 2014 01:25, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With the Icehouse release we announced that there would be no further backwards-incompatible changes to HOT without a revision bump. However, I notice that we've already made an upward-incompatible change in Juno:<br>

<br>
<a href="https://review.openstack.org/#/c/102718/" target="_blank">https://review.openstack.org/#<u></u>/c/102718/</a><br>
<br>
So a user will be able to create a valid template for a Juno (or later) version of Heat with the version<br>
<br>
  heat_template_version: 2013-05-23<br>
<br>
but the same template may break on an Icehouse installation of Heat with the "stable" HOT parser. IMO this is almost equally as bad as breaking backwards compatibility, since a user moving between clouds will generally have no idea whether they are going forward or backward in version terms.<br>

<br>
(Note: AWS don't use the version field this way, because there is only one AWS and therefore in theory they don't have this problem. This implies that we might need a more sophisticated versioning system.)<br>
<br>
I'd like to propose a policy that we bump the revision of HOT whenever we make a change from the previous stable version, and that we declare the new version stable at the end of each release cycle. Maybe we can post-date it to indicate the policy more clearly. (I'd also like to propose that the Juno version drops cfn-style function support.)<br>
<br>
</blockquote></div>+1 for idea creating new version for each release cycle. I think it will help to modify format and additional features easier without backward compatibility problems.</div><div class="gmail_extra"><br>
</div><div class="gmail_extra">+1 for rejecting cfn functions in HOT. Sometimes it leads to confusing situation (F.e. when user try to use Fn::GetAtt instead of get_attr in HOT, where we have not such function).</div></div>