Oliver Bertuch (Mar 11 2024 at 13:41): Oliver Bertuch (Mar 11 2024 at 13:41):@Jan Range @Philip Durbin I have a user of Jülich DATA asking for API compatibility. They want to code automations in Python and are wondering about backward compatibility of the backend API. The only breaking change I remember right now is the JSON problem with DV 5.9+ (https://github.com/gdcc/pyDataverse/issues/143) Anything else that comes to mind?
Philip Durbin 🚀 (Mar 11 2024 at 14:08):That one is be enough that we should probably list it on our new list of breaking changes: https://guides.dataverse.org/en/6.1/api/changelog.html
Philip Durbin 🚀 (Mar 11 2024 at 14:08):There are a few others listed and of course you can see the preview at https://preview.guides.gdcc.io/en/develop/api/changelog.html
Oliver Bertuch (Mar 11 2024 at 15:17):Thx! Should I create an issue / PR for it?
Philip Durbin 🚀 (Mar 11 2024 at 15:29):Yes, please!
Philip Durbin 🚀 (Mar 11 2024 at 15:29):We started with 6.x stuff but I'd like to backfill as far back as we can.
Oliver Bertuch (Mar 11 2024 at 16:08):Ha! Looks like we could use this old issue where you already mentioned the new guide section: https://github.com/IQSS/dataverse/issues/9549
Oliver Bertuch (Mar 11 2024 at 16:11):Hmm... Reading the code from the pyDataverse PR and from the Datalad PR how are these changes related???
Philip Durbin 🚀 (Mar 11 2024 at 16:21):I'm not sure. New Zulip topic? :grinning:
Oliver Bertuch (Mar 11 2024 at 16:29):I'm adding a new issue anyway. #10362
Philip Durbin 🚀 (Mar 11 2024 at 16:33):Looks great. Much appreciated!
Sebastian Höffner (Jul 19 2024 at 23:57):Not sure if this is the right channel, but @Philip Durbin asked me to copy my thoughts from pyDataverse#197 here, and this is about API compatibility:
In general, the /vX/ path parameter should be used to handle versioning, but it appears that the versions returned by /api/info/version track breaking changes much better, as /v1/ seems to have been static from what I can tell, without having too much insights into the project.
It all depends on what the stance on API-level support for pyDataverse is -- i.e., should every version in general just support whatever API was available at that time, or should it also support older API levels for some time.
In the former case, yes, getting the DV_VERSION from the API is sensible -- or the asserts could even be removed or relaxed to be more like "is a version present".
However, this might also cause tests to fail without having an idea as to why they fail. In this case, I knew that if something unrelated would break, it might also be API-Version related. If the version would be selected from the API itself, I wouldn't know this.If the goal is to support differently versioned Dataverse instances, it would even be more difficult, but one could either select a version with DV_VERSION or auto-detect the API level using the API.
Philip Durbin 🚀 (Jul 20 2024 at 18:15):@Sebastian Höffner sure, this seems like a good place, thanks.
Philip Durbin 🚀 (Jul 20 2024 at 18:16):Oliver Bertuch said:
The only breaking change I remember right now is the JSON problem with DV 5.9+
We did finally document that breaking change:
Explain that 5.6 introduced a breaking change to the create dataset API #10467
Last updated: Nov 01 2025 at 14:11 UTC