Hm, I don't quite get how that works I guess :/

Hm, I don't quite get how that works I guess :/

What do you mean? From the test failures, it seems like that there are some AppStore code leftovers. But besides that, I'd first like to deprecate this functionality and then remove it. Removing it just like that might be too harsh.

I'd first like to deprecate this functionality and then remove it.

Agreed. Removing a future in a minor upgrade without any deprecation is really a bad idea IMO.

btw, could you provide some justification for this removal?

ok. I got why you propose this PR. but I still prefer to remove it in a major upgrade. (maybe someone could help me to remove the deprecated --mirror option at the same time)

but I still prefer to remove it in a major upgrade

Given the current lack of users and maintainers, it might be too much burden to adhere to semantic versioning. The way I see it right now is: fix regressions in patch releases, add new features, deprecate and remove the old ones in minor releases. At the current state, a major release is out of the question, IMO.

maybe someone could help me to remove the deprecated --mirror option at the same time

Removed in #1083.

#1088 is filed to deprecate the component first.

Let's close this one in favour of #1088 then :)