Should we do something more thoughtful when a new Central API method is called against an older server?

[lognaturel]

A user can call a pyodk method that uses an endpoint that doesn't exist on their Central server. Currently, they'll receive a 404 when that happens. There can be more subtle cases like using query parameters that don't exist or relying on behavior that has evolved a bit.

We could have a concept of a required Central version and check that against the server to provide better errors.

I am currently feeling like it's not necessary but I do think about it every time we add new functionality. Maybe this is something we could capture our current philosophy around in the README? What do you think @lindsay-stevens?

[lindsay-stevens]

So we are anticipating someone who wants to use the new pyODK + old Central + expects to be able to use new Central features? It's possible but I don't know if it would be common enough to be a win vs. the effort to maintain.

We probably should do this anyway, but I think it would suffice to put the Central version that was used to test each release in the README.

[lognaturel]

someone who wants to use the new pyODK + old Central + expects to be able to use new Central features

Yes. I think a realistic scenario would be something like I’m a data manager, my Central server is managed by someone at my organization who I don’t know directly and it’s a few versions behind. I use the pyodk docs to achieve some goal I have, inadvertently using endpoints my server doesn’t have. I get weird server errors I don’t understand and I’m not sure where to go from there.