My history with ECS, is that any release no matter how major or minor, will change core APIs. So that old code must be updated to it. And if multiple assets depend on ECS, they will generally limit asset choices to only specific ECS versions.
Is this something I should be concerned about for developing an SDK package dependent on ECS/Jobs? If it is, are there steps short of maintaining support for different SDK versions that could mitigate the concern?
Any related advice would be helpful as well. Perhaps since we are into the official release, that most general use cases of the API will be maintained to support the 1.0.0 version? At least until version 2.
In theory, it should be supported now. In practice, it can be quite difficult to make a package that fits well in a variety of projects without having to do some gymnastics. And you’ll likely need to rely on asmref for a few things. Also, Unity can decide that any undocumented feature is no longer a feature but rather a coincidence and just remove it, which is a problem because most of what is useful for custom packages is undocumented.
Support whatever you are most comfortable supporting, and be prepared for frustration, as Unity is very tightlipped about their trajectory at the detail level package developers care about.
That should no longer be the case with Entities 1.x releases - now that the relevant packages are in release status, you can expect them to stick with Semantic Versioning unless that’s impossible for some reason.