The release of this change was unintended and is a result of an error on our part.
We have rolled back the changes. Typically, if there is a potentially disruptive change, we issue a deprecation warning in our documentation and allow sufficient time for users to adapt.
We apologize for the inconvenience this has caused and will take measures to prevent such occurrences in the future.
However, deprecation warning in documentation is not enough and not an industry standard. Can you start doing release notes and send emails to API users?
No one in the world will go and check your documentation every day for new deprecation warning. I am sure neither you do that for your upstream libraries, imagine all your upstream packages asked you to go through their documentation everyday to get deprecation warnings.
This is not a trivial request, if your API is not ready for production please communicate the same. If it is, at-least the process needs to be fixed immediately, we can wait for features but not processes.
We acknowledge the importance of a robust communication strategy for API changes and are committed to implementing a more formalized process. We will ensure to establish a definitive communication mechanism to notify our users about such deprecations with clear timelines. The current practice of noting deprecations in our documentation serves as an initial alert, particularly aimed at orienting new users correctly from the outset.
Rest assured, we are actively working on enhancing our communication protocols for a seamless user experience.