Hi, If I start working with this API, how can I:

1. Easily know when it has been: a) Changed to add a new feature? b) Tweaked and existing description of behavior/feature? c) Corrected for error/clarification?
2. Grab those changes, no more and no less.
3. Unambiguously point the version I started with no matter what has gone on, or is going on?
4. Clearly communicate to somoene what I'm working on (have implemented) regardless of the current state of the API?

Am I nuts to think that major.minor.patch numbering has some value - even while the major number is 0?

Thanks Tim.

Apologies for not being clearer, in my mind the feilds you mention raise some of the questions I listed.
I assume the implementation version is something the implementer is responsible for, so not directly relevant here. Although, being given it's version number does raise the same type of questions.

Example: I get given the data specification_version=0.x, I come here and see the spec is at version 0.y...
Now what do I do?

So, in the release early/ugly tradition....

I started the scar project as an experiment to:

1. provide a convenient way to answer some of questions I posed earlier (I won't reiterate them here)
2. extract the spec detail and description from the wiki's html and, hopefully, make them reusable (JSON)
3. directly use the spec's detail and description in an implementation.

It is early/ugly, no extraction or refactoring has yet started. I'm just exploring writing 'stories' for the current spec's html page contents. My first intention is to extract the Cloud resource spec, and see if I can usefully employ that detail and description in an implmentation. If that works, I'll move on to other parts.

Appreciate any feedback and contributions. Just fork the project, change/experiment however you wish and send a Github pull request to whoever you think would be interested in having your changes, e.g. hedgehog :) Scar contributor documentation is a little light but reading some of the rake tasks and feature files will give you some idea of what has gone on. There is no TODO list as yet but you'll also see things that need cleaning up e.g the coderay css/code-highlighting.

I'm not a lawyer so please shout out if I've done something that breaks the letter or spirit of the license.
It is a one-click change to make the Github repo private so I won't argue if you think this project (and the forks it spawns) are unhelpful.

Regards