Open Stack

On 08/07/14 10:13, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2014-07-07 14:25:50 -0700:
>> 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.
> Sounds like a bug in Juno that we need to fix. I agree, this is a new
> template version.
>
>> (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.)
>>
> A good manual with a "this was introduced in version X" and "this was
> changed in version Y" would, IMO be enough, to help users not go crazy
> and help us know whether something is a bug or not. We can probably
> achieve this entirely in the in-code template guide.
>
Intrinsic functions are manually documented, but it would be great to be
able to generate this for resource types, properties and attributes. The
SupportStatus structures are all there, it just takes someone to go
through the release history and populate them. Users often trip over
attempting to use a documented new thing on an older heat release.