Idea: Define `version` and `spec` in scheme files & Meta file for templates

[ln4r3n]

For future proofing the project i think it's necessary to add version (for possible color changes) and spec to schemes files.

Also I propose another metafile for templates (parsed by builders):
tinted-template.yaml with contents such as (my example is the official vim plugin),this needs to be present in the root of the template repo:

name: base16-vim
version: 0.1        # template version
system:             # supported system and spec
  - base16: 0.11
  - base24:
      - 0.11
      - 0.12        # possible future spec
maintainer:
  - https://github.com/BonaBeavis
  - https://github.com/JamyGolden
dependecies:        # array for checking if dependecies are present
postprocessor:      # for e.g converting the generated files to binary format

With these changes the user and builder both can easly check for compatibility, supported systems, etc.

[JamyGolden]

Right now all the changes that have been made have been backwards compatible. Once we add variables to a new spec, those variables in the builder will default to some base0x value if it's not provided. I don't think adding a more strict version system like you're suggesting is a bad idea if we were to start adding breaking changes. Making the decision to add breaking changes is quite a big step though and it might be easier to create a new scheme spec if we were to do that. What do you think @belak?

[JamyGolden]

The changes we've made to the styling spec have all been backwards compatible and all (all as far as I can remember) of the changes we've made to the builder spec have been backward compatible. We've been quite intentional about that since we don't want to isolate people working on base16 things who don't follow the tinted-theming version of the spec.

We may make a breaking change at some point though, but it might be under a different scheme system name. This is probably the biggest change we're discussing, but it's still a superset of the legacy base16 and is backwards compatible #99

Having said that, your suggestion includes multiple systems and it makes sense for systems to have breaking versions, so I do see value in your tinted-template.yaml file suggestion. I also think having a template version would be valuable since at the moment the only way to track a version would be to look at the git hash.