Ingvar Stepanyan

@mikesherov I think when @gibson042 wrote his previous comment > Don't you mean type: "DoExpression"? main type of node was "BlockStatement", but @hzoo edited it afterwards, so it's now "DoExpression",...

This I'd a living standard - means we simply follow ECMAScript versioning here and we definitely don't break backward compatibility (see principles PR), so there's little benefit to introducing separate...

> In that case, changes are _definitely_ moving too fast. They are _definitely_ not fast given that most of these features were already implemented and now we're just formalizing them...

It's living standard by purpose, and yes, ES6 AST is just not finalized yet (as well as ES6 itself is not officially released). I'm with @sebmck here and I really...

Things like #70 that you mentioned are not breaking changes - those are just adjustments that make rules more obvious/stricter, and don't really change how things are parsed, transformed or...

Semantic versioning is needed when you have ecosystem where things can depend on specific ranges of versions. However, if any of participating members (Esprima, Acorn, SM) starts supporting other versions...

> or a scheme allowing an escape hatch for sufficiently valuable backwards incompatibility That's the reason of why we don't see your point - we just don't break it. The...

Well, we definitely don't aim to reflect (reimplement) all the rules from entire ES6 spec in data structure spec, but rather to give clear representation for each syntactic construct that...

> Maintaining a diff between different ES versions is a bit overhead. Can we tag certain commit with `es2015`, `es2016`? Hmm how would we do that cleanly for existing history?...

I think this would be a significant breaking change to split up commutative operations vs non-commutative in separate nodes. It shouldn't be hard to rebalance tree afterwards if it's something...