And that is why any sane (experienced?) API and/or standard author should have versioning in mind at all times. In my experience there is no such thing as "the" API or "the" standard.
Their API is versioned (the json api version happened to be v2). But they don't feel the need to build a brand new v3 just to chase a moving target, especially since customers (and they themselves) are already using their v2.
There was an unversioned spec posted for months that looked usable, then suddenly they announced a complete rewrite as "RC2". Calling it a relase candidate was misleading, though - almost everything got changed again for "RC3".
I definitely can see why you'd see RC3 as a complete rewrite, but I don't understand why you'd feel that way about RC3. There were definitely changes, but they were much smaller and motivated by significant feedback by users who opened issues in response to RC2.
For example, RC2 mandated that all fields were dasherized. We made field names opaque in RC3.
At this point, we're pretty much nailing down tiny details and included this language with RC3:
JSON API is at a third release candidate state. This means
that it is not yet stable, however, libraries intended to
work with 1.0 should implement this version of the
specification. We may make very small tweaks, but
everything is basically in place.
