Open Stack

On 07/07/14 20:02, Steve Baker wrote:
> 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

I'm hearing consensus on this general approach, so I put up an 
implementation for further comment:

https://review.openstack.org/105558

cheers,
Zane.