On 08/07/14 09:25, Zane Bitter 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 on setting the juno release date as the latest heat_template_version, and putting list_join in that.
It seems reasonable to remove cfn-style functions from latest heat_template_version as long as they are still registered in 2013-05-23 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
