Replace api field with api_compatibility

[gidsi]

This way you can build a spaceapi file that is compatible to multiple versions to make a soft migration to new versions possible.

At least as long you don't need to use fields that exclude each other (e.g. using hPA barometer unit in 0.13 vs. hPa in 0.14).

Renamed the field so it won't be incompatible to versions 0.13 and lower.

Not sure if the field should still be required, but that's something we can also discuss later.

[dbrgn]

Generally in favor!

It would require to clearly state that unknown fields are OK. We should also remove the notes about ext_ fields.

[rnestler]

Alternative field name proposals:

• "apis"
• "compatible_versions"

[gidsi]

I would be up to:

• compatible_versions
• api_versions

I kinda start to dislike apis because i would somehow expect something completely different in our context (e.g. something like the feeds attribute).

[gidsi]

Generally in favor!

It would require to clearly state that unknown fields are OK. We should also remove the notes about ext_ fields.

I would keep the ext_ fields too. This way you can always use fields inside your file that we will never touch.

[dbrgn]

What about api_compat?

[gidsi]

What about api_compat?

I would be fine with api_comptability or comptability. I don't like compat, never did. I can't really tell why, feels like someone stopped in the middle of writing.

Since it's a personal thing i would agree if you two agree it the best choice.

[dbrgn]

I'd be OK with api_compatibility (not api_comptability 😉), even though I generally prefer shorter keys.

[gidsi]

I'd be OK with api_compatibility (not api_comptability wink), even though I generally prefer shorter keys.

api_compatibility it is :)