Closed gidsi closed 4 years ago
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).
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.
What about api_compat
?
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.
I'd be OK with api_compatibility
(not api_comptability
:wink:), even though I generally prefer shorter keys.
I'd be OK with
api_compatibility
(notapi_comptability
wink), even though I generally prefer shorter keys.
api_compatibility
it is :)
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.