ideditor / schema-builder

🏗🏷 Create tagging schemas for iD
ISC License
12 stars 16 forks source link

allow multiple `prerequisiteTag`s #87

Open k-yle opened 1 year ago

k-yle commented 1 year ago

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.

tordans commented 1 year ago

The docs here also need updating I think. Somewhere here https://github.com/ideditor/schema-builder#prerequisitetag

k-yle commented 1 year ago

thanks @tordans, I've updated the README

tordans commented 3 months ago

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.

k-yle commented 3 months ago

a. I don't think its great to have a key value that can hold an array. It should really be values 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

tordans commented 3 months ago

Are you suggesting that we allow both value XOR values? Or should value be replaced by values?

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.

tordans commented 2 months ago

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.