this introduces a flavor of the same problem, which is that it makes it impossible to upgrade one side without upgrading the other side due to strict semver checking.

e.g. if you want to fix a bug on the python side, you will also have to rebuild and redeploy javascript, even if its not otherwise modified.

We already do this though - there is no situation in which the version of perspective-python would != the version of the Javascript packages, since the entire versioning scheme is hooked up to lerna dist which updates all lerna-ized packages at The only part that isn't hooked up to lerna dist is disting new versions to pypi, which we are admittedly behind on right now.

I have firsthand experience with a framework in which you could control backend updates, but not frontend updates. The reason we switched to this versioning scheme in the first place was to make it easier for your team to get changes out on the backend without worrying about my team getting the JupyterLab extension updated

@timkpaine I appreciate the insight and acknowledge that this change will make it more difficult for version-restricted/role-partitioned environments to upgrade ... c'est la vie.