Performance benchmarks:

Wait, actually, I think you can just change it to a PendingDeprecationWarning instead of removing it.

I didn't know such thing existed, makes more sense in this case.

It's quite a niche thing I happened to know by accident.

Thanks!

I think we can update these to full DepreciationWarnings again.

We do have to pick a version when to deprecate. Following full SemVer is needs to be 4.0, but I think we made an exception for the visualization, so we can also do 3.5 for example.

We should also add a few lines to the migration guide.

I actually have no idea how versions and migration guide works. But I think we'll need to update the migration guide with the new visualization changes because it changed a lot with the introduction of portrayal components and space renderer.

@Sahil-Chhoker we follow https://semver.org/. It basically comes down to only make breaking changes between major releases (x.0.0). Minor releases (x.y.0) are for new features and patch releases (x.y.z.) is for fixing bugs, updating docs, maintenance, etc.

For visualisation we have made an exception, we don't apply SemVer strictly to keep development speed up.

If we plan to make a breaking change, we normally deprecate it at least one minor release before removing it (which would be a major release). We do that by adding notes to the docs and release notes, making sure it isn't used in any examples anymore, making sure the replacement is fully ready and stable, etc. We also add notes to the migration guide.

So here we plan to remove something, and the replacement is already ready, examples are updated, so we can deprecate it. I think everything is already done for that, except adding a note to the migration guide on how to update and actually updating to the full DepreciationWarnings.

Does this help?