> But… CRAN had also rerun the tests for all packages that depend on mine, even if they don’t belong to me!
When you propose a change to something that other things depend on, it makes sense to test those dependents for a regression; this is not earth shattering.
If you want to change something which breaks them, you have to then do it in a different way. First provide a new way of doing something. Then get all the dependencies that use the old way to migrate to the new way. Then when the dependents are no longer relying on the old way, you can push out a change which removes it.
>If you want to change something which breaks them, you have to then do it in a different way.
Almost every other package repo works differently and publishing packages which would break other packages is more than common, it is the standards way to publish updates.
>Then get all the dependencies that use the old way to migrate to the new way. Then when the dependents are no longer relying on the old way, you can push out a change which removes it.
This is actually how no software repo works as it is actually insane.
Nope!
- Breaking things obviously insane rather than not breaking things.
- Staged obsolescence is sane compared to breaking things, and compared to installations carrying multiple versions of the same package.
There being single version of every package in any given installation, and every package carefully managed for backwards compatibility, removing features only when everything has migrated off them, is utterly sane.
There may be exceptions. (The idea that there are never exceptions is insane). Suppose that it is discovered that there is no secure way of using some API, and there is a real threat: it has to be removed.
I think that a good way forward would be to identify the packages which use the API, and contact all the maintainers for an emergency conference.
The package system should also be capable of applying its own patches to packages; if something must break for backwards compatibility, the package system should provide patches to fix the broken packages until the upstreams develops their own fixes.
Have you ever worked with a package manager for a programming language?
In almost every case it is the sole duty of the people using the packages to ensure they adhere to whatever standards they desire. This is how packaging software works in basically every case.
>The package system should also be capable of applying its own patches to packages; if something must break for backwards compatibility, the package system should provide patches to fix the broken packages until the upstreams develops their own fixes.
This is just you not understanding software. This is obviously not possible, it also is not desirable.