paul121
commented
3 years ago Thanks for starting these thoughts @mstenta ! I created a new issue for generalized farmOS 2x support: #98
After thinking more about this, I think the easiest path forward is to enforce that the server version matches the Aggregator API version. We can maintain both /api/v1 and /api/v2 endpoints, but remove areas from /api/v2. Another thing to consider are the response/request formats that differ between farmOS 1x and 2x. More thoughts here: https://github.com/farmOS/farmOS-aggregator/issues/98#issuecomment-729112041
In farmOS 2.x, "Areas" are being migrated to Land/Structure/Water asset types. There will not be an "Areas" taxonomy.
This will also need to be deprecated in farmOS.py.
Need to think through what deprecation actually means in this context...
We'll still need to support the endpoint for 1.x sites - there will be a period of overlap when some sites are on 1.x and others are on 2.x.
There may also be cases where a site gets upgraded to 2.x, but there are still requests being made to it using the old endpoint.
Maybe we add support for 2.x alongside 1.x, with deprecation notices, and then eventually make the decision to drop 1.x support (perhaps by bumping the Aggregator itself to 2.x, similar to what we'll be doing in Field Kit). Then, anyone hosting the Aggregator can decide when to jump to 2.x, based on the sites that they need to connect to, and whether or not they've all be upgraded.
Perhaps this issue should be generalized to "farmOS 2.x Support" more broadly.