wiige To be honest, we’ve had internal discussions in the past about whether we should provide documentation for each version, but in the end, we decided not to pursue that approach.
In fact, across most of our documentation, we follow a policy of only presenting the latest information. While you specifically mentioned the API documentation, the same applies to the Spine Editor user guide as well. It includes explanations of features that did not exist in older versions, and in most cases, we do not specify which version introduced a given feature.
I wish I could refer back to the exact discussion logs from when we debated this internally, but I wasn’t able to locate them, so this explanation is partly based on my recollection. That said, there are two main reasons behind this decision:
- We strongly recommend using the latest version of both the editor and the runtimes. This is also why our licensing model does not separate versions—we provide access to all versions of the editor under a single license. We make careful efforts to minimize breaking changes and to make upgrades as smooth as possible, so that users can keep their projects up to date. Because of this, it makes sense for the latest version to serve as the standard, and for the documentation to consistently reflect that.
- Even without version-specific API references, the scripts themselves include sufficient summaries and explanatory comments. By reading the source code appropriately, users can understand how each API should be used.
For these reasons, the absence of a version selector is not due to technical limitations, but rather a deliberate decision based on our overall philosophy.
That said, as you may have noticed, we do separate the reference pages for beta and stable releases. In cases where information is still subject to change, we provide it on separate pages accordingly.
I hope this clarifies our approach.
