
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div apple-content-edited="true" class=""><div class=""><br class=""></div></div><div><blockquote type="cite" class=""><div class="">On 20 Dec 2014, at 03:01, Dmitri Zimine <<a href="mailto:dzimine@stackstorm.com" class="">dzimine@stackstorm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Another observation on naming consistency - mistral uses dash, like `for-each`. </div><div class="">Heat uses _underscores when naming YAML keys. </div><div class="">So does TOSCA standard. We should have thought about this earlier but it may be not late to fix it while v2 spec is still forming. </div></div></div></blockquote><br class=""></div><div>Dmitri,</div><div><br class=""></div><div>We thought about it long ago. </div><div><br class=""></div><div>So my related comments/thoughts:</div><div><ul class="MailOutline"><li class="">We didn’t find any strict requirements about using snake case in YAML</li><li class="">as well as in OpenStack</li><li class="">We also didn’t find any technical problems with using “dash case"</li><li class="">One of the reasons to use “dash case” was a suggested style of naming workflow variables using snake case. So not to confuse workflow language keywords with workflow variables we consciously made this decision.</li><li class="">v2 is still forming but I’ve been totally against of introducing backwards incompatible changes into it since the beginning of October since we promised not to when we released 0.1 version. All the changes we’re now considering should be 100% backwards compatible with all existing syntax. Otherwise, it will be not easy to gain trusts from people who use it. Again, all changes <b class="">must be additive</b> within at least one major version of DSL. If we gather enough feedback that some of the things need to be changed in a non-backwards compatible way then we will probably create v3. Otherwise, why do we need versioning at all?</li></ul></div><div><br class=""></div><div><div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div></div></body></html>