Deprecation within our team is a complex topic that we’ve been discussing at length. Babylon maintains a strong commitment to backward compatibility, even between major versions. This means that code written for Babylon 3 should ideally work seamlessly with Babylon 6. We only break backward compatibility when a browser API changes, necessitating adjustments for continued functionality.
In terms of deprecation in a back-compat-enabled framework, we follow a specific approach. When we decide to deprecate a function or API, we mark it as deprecated without removing it. Instead, we continuously introduce new functions, create updated versions of APIs, or extend the contract of specific functions to ensure smooth transitions for developers.
For instance, our physics engine architecture offers an excellent example. We maintain the old API, allowing users to upgrade to newer versions of the engine without issues. However, if developers wish to adopt the new physics architecture, they will need to make some code adjustments to ensure compatibility.
It’s important to note that the deprecation policy applies to current public packages like “babylonjs” and “@babylonjs/core.” These packages will remain backward compatible. On another note, we are working on porting the engine to a more ES-modules-friendly architecture, but this is still a work in progress and not yet ready for demonstration. Once completed, this new package will not be backward compatible, as the API will undergo significant changes, and we will remove deprecated functions.
However, the development of this new package is quite extensive and will require substantial time and effort before it becomes fully functional. Until then, our deprecation approach will continue to ensure smooth transitions for our users while maintaining a commitment to backward compatibility.
TL;dr - we do deprecate functions and APIs, but we never remove them from our public APIs, prioritizing the seamless experience for developers across different versions of Babylon.