On 8 July 2014 01:25, Zane Bitter <[email protected]> wrote: > 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: > > https://review.openstack.org/#/c/102718/ > > So a user will be able to create a valid template for a Juno (or later) > version of Heat with the version > > heat_template_version: 2013-05-23 > > 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. > > (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.) > > 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.) > > +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.
+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).
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
