Hi, On 04/02/2020 14:58, Patrik Dufresne wrote: > I'm definitely looking toward a similar solution where it's seamless. > The more I'm thinking of it, we may need to change the code in > rdiff-backup to help us. What would really help is having rdiff-backup > calling a different executable in the remote schema. Instead of calling > "rdiff-backup" it should call rdiff-backup2.0.0. And rdiff-backup could > be a symbolic link to the default version, either 1.2.8 or 2.0.0. That > would really simplify the migration process for everyone. > > > @EricZolf <mailto:ewl+rdiffbac...@lavar.de> Do you think it's feasible ? > It would mitigate all the migration issue and API incompatibilities. We > could also call "rdiff-backup2" (with only the major version) and bump > the major version only when an API incompatibility get introduced in the > code.
The issue is that wheels don't support links, at least not by default (it seems it's possible to fiddle them in, but I haven't tried and it sounds again ugly). There also isn't anything you can't configure / tweak yourself as part of the installation you anyway need to do (as 1.2/1.3 and 1.9/2.0 use different versions of Python, only the binary itself need attention, the libraries are anyway in different places) and using --remote-schema. Also, so late in the release cycle, I'm reluctant to change even more things. Hope you can live with it, Eric