Add specification version field

[b-wils]

Since v is already in use for bodymovin version, using sv here. Open to alternatives.

[mbasaglia]

I wonder if using an increasing integer is easier than a string (A tool could just use comparison instead of having to parse the version number)

[b-wils]

I wonder if using an increasing integer is easier than a string (A tool could just use comparison instead of having to parse the version number)

I'm in favor.

I know JSON Schema can't really parse version strings and I can see us wanting some conditional validation down the road.

I think we would still want to track major and minor versions, so probably a field for each.

[kudanai]

To complete the context here, lets document what the version will look like

[Aidosmf]

lgtm, but let's wait for @mbasaglia ^..^

[mbasaglia]

I'd probably wait to merge this until everything else for v1.0 is merged so we don't publish a schema with the version number

[mbasaglia]

We should probably specify explicit version numbers, someone publishing a lottie with version 2.0.0 ver: 20000 would not be valid as there's no associated schema.

[b-wils]

I think the key question here is if lotties created in the future with a new version should be considered invalid for older schema?

If a future lottie otherwise passes an older schema, I think that should still be good enough to be considered valid.

I am concerned about extra work to keep schemas updated in all the tooling, particularly for smaller revisions and/or platforms that have a more involved release process, such as wear.

[b-wils]

I'd probably wait to merge this until everything else for v1.0 is merged so we don't publish a schema with the version number

That's a good point, we don't want different "1.0" schemas existing. We can work the version increase into the release process once we fully define it.

[mbasaglia]

Maybe we could use version 0.0 for now and change it to 1.0 before release

[b-wils]

Maybe we could use version 0.0 for now and change it to 1.0 before release

Updated this to 0.1.0 for now and included it in the schema itself. Once we figure out the release process, we'll need to decide where draft specs get published and when we want to update the version number. It may be worth having an additional "isDraft" meta-field in the schema as well.

[mbasaglia]

the wording here is a bit awkward perhaps it can be rephrased?

also consider using upper case for SHOULD / MAY when defining compliance behaviour as per RFC 2119

[b-wils]

Cleaned this up a little bit. I think it's still a bit awkward but hopefully better than before. Welcome to any suggestions here.

[mbasaglia]

The URI might be different once we figure out releases, by the way I think in the file name we should use the dotted version number for readability (eg: 0.1.0)

[b-wils]

Agreed, we can update this as needed. One thing to note is that this doesn't have to be a network locator though it's more helpful if it is.

[mbasaglia]

Since I'm writing about the specs release process in the contributing file, I'll mention semantic versioning in there too