# Scheduling breaking changes we have on our radar **URL:** \ **Category:** Development & Design\ **Created:** [March 25, 2024, 9:27am UTC](https://forum.openrefine.org/t/scheduling-breaking-changes-we-have-on-our-radar/1410 "2024-03-25T09:27:28Z")\ **Posts on this page:** 1\ **Showing post:** 13
**Author:** ![tfmorris](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.openrefine.org/tfmorris/32/17_2.png) [@tfmorris](https://forum.openrefine.org/u/tfmorris)\ **Post date:** [August 26, 2024, 5:13pm UTC](https://forum.openrefine.org/t/scheduling-breaking-changes-we-have-on-our-radar/1410/13 "2024-08-26T17:13:04Z")
Replying in reverse order to DaxServer, Thad, and Antonin: 1. Using OpenAPI/Swagger to document the API and generate clients is definitely the way to go, but I'm assuming this would be more than just a straight documentation of the existing API, but also a cleanup with consistent return formats, etc. 2. Thad's quotes from Stefano are from: - Stefano on GREL - [https://groups.google.com/g/openrefine/c/lwGkVMTt-Vc/m/riz8IzjavwkJ](https://groups.google.com/g/openrefine/c/lwGkVMTt-Vc/m/riz8IzjavwkJ) - Stefano on extension references - [https://groups.google.com/g/openrefine-dev/c/bBVUWc6wEog/m/inEE22Tc94kJ](https://groups.google.com/g/openrefine-dev/c/bBVUWc6wEog/m/inEE22Tc94kJ) 1. I don't see a rewrite such as proposed by Antonin as something which is feasible. Big bang rewrites always seem more attractive and easier than the messy alternative of dealing with existing code, but they always take longer than predicted and often fail altogether. [Joel summarizes](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/) my view on this pretty well. --- _[View the full topic](https://forum.openrefine.org/t/scheduling-breaking-changes-we-have-on-our-radar/1410)._