Open k-yle opened 1 year ago
The docs here also need updating I think. Somewhere here https://github.com/ideditor/schema-builder#prerequisitetag
thanks @tordans, I've updated the README
I am wondering about two things…
a. I don't think its great to have a key value
that can hold an array. It should really be values
instead.
b. The note on breaking changes is true for iD, but it is not true for GoMap, EveryDoor and other data consumers of the tagging schema repo. What would be a good migration path? The easiest would be to make this a major release and explain the update path for the other apps.
I don't see any way to do a soft migration with deprecation and both solutions being present for one release cycle. That would be ideal to release fast but allow consumer apps to update afterwards.
a. I don't think its great to have a key
value
that can hold an array. It should really bevalues
instead.
Are you suggesting that we allow both value
XOR values
? Or should value
be replaced by values
?
b. The note on breaking changes is true for iD, but it is not true for GoMap, EveryDoor and other data consumers of the tagging schema repo.
Based on 544f546, it looks like there's about to be a major release, so we may as well label this as https://github.com/ideditor/schema-builder/labels/breaking
It would be worth prewarning GoMap and EveryDoor, since they're both fetching directly from the main branch...^1 Ideally all data consumers would be setup to only fetch v6.x.x
, for example, using https://unpkg.com/@openstreetmap/id-tagging-schema@6/dist
Are you suggesting that we allow both
value
XORvalues
? Or shouldvalue
be replaced byvalues
?
I think the best would be to make it a breaking change and migrate everything to values
. Maybe the builder should have a fallback to listen for value
as well (and make it an array) so we don't have issues with updating all the code at once over at https://github.com/openstreetmap/id-tagging-schema
…so we may as well label this as breaking
Sounds like the cleanest solution to me.
It would be worth prewarning GoMap and EveryDoor
Agreed. Lets wait for Martin and then create an issue to ping the known data users.
On the question of a mayor release and how to inform consumers of the data:
@tyrasd just told me he looked into this with a breaking change in 2022 (eg. here, here). Most editors should be using a specific major release. GoMap does not, but that is fine because Bryce pulls the change manually via script so he is informed of breaking changes this way.
Closes #137
Relates to https://github.com/openstreetmap/iD/pull/9511.
This is not a breaking change if that PR is merged first.See https://github.com/openstreetmap/iD/pull/9511 for details.