How can one define remapping from one vocabulary version to another?

[ManonGros]

For some of the GRSciColl vocabulary, I would like to have a first version that is close to (or identical to) the current enums we have. In the future, these might change a bit more. But is there a way to formerly describe things like: "what was mapped to concept X in the vocab version 1 should be mapped to concept Y in the vocab version 2"?

Right now all I can think of is writing a GitHub issue for Marcos. I was wondering if there was a better way.

[CecSve]

An issue has to be created (or this can be the issue) - versioning is not implemented yet but will be eventually. I saw this version change documentation example for ABCD yesterday and perhaps we can do something similar with labels defining what the change is:

The documentation should live on tech docs.

[marcos-lg]

Besides the documentation, which is a good idea, we can also add a comment field in the deprecate action of the API.

[marcos-lg]

I was reviewing this issue again. For deprecations of concepts we actually can specify the concept that replaces the deprecated one. What we are probably missing is to generate a report with all the changes when a new version of the vocabulary is released. Right now we only allow to add a comment to the release: https://api.gbif.org/v1/vocabularies/LifeStage/releases

[CecSve]

That's great for tracking concepts. Do we have anything in place for tracking what happens to the hidden values? It might be for another issue, but I could imagine concept changes would require mapping changes as well, in most cases.

[marcos-lg]

No, it's only for concepts but not for labels. But the tracking of labels(hidden and the others) is doable since we store the release versions so we can just compare the current version with the previous one.