Deprecating a feature doesn't mean removing it immediatelly. Can you, please, keep the code for now and just print the error message?

The error message being the message about deprecation.

Deprecating a feature doesn't mean removing it immediatelly. Can you, please, keep the code for now and just print the error message?
The error message being the message about deprecation.

In this case, I would prefer to edit the error message and say, that it was "removed" instead of "deprecated". Would you mind it?

I mean, there is no reason to keep the code here for any longer. That exact functionality was implemented in Copr's copr_prune_results.py script, which was also updated to not use prunerepo with --cleancopr anymore. I wouldn't care and let the code here for how long you prefer, but it bothers me, that it contains known bugs and since it is deprecated, new features don't update it - and therefore it would e.g. remove files even with --dry-run from PR#3. Because of that, I find keeping the clean_copr code here more dangerous than useful.

Deprecating a feature doesn't mean removing it immediatelly. Can you, please, keep the code for now and just print the error message?
The error message being the message about deprecation.

In this case, I would prefer to edit the error message and say, that it was "removed" instead of "deprecated". Would you mind it?
I mean, there is no reason to keep the code here for any longer. That exact functionality was implemented in Copr's copr_prune_results.py script, which was also updated to not use prunerepo with --cleancopr anymore. I wouldn't care and let the code here for how long you prefer, but it bothers me, that it contains known bugs and since it is deprecated, new features don't update it - and therefore it would e.g. remove files even with --dry-run from PR#3. Because of that, I find keeping the clean_copr code here more dangerous than useful.

I understand that but I prefer releasing a minor version with deprecation first. Then later do major version bump with the removal. Can we update the code to account the dry-run or say at least say --cleancopr is incompatible with --dry-run?

I understand that but I prefer releasing a minor version with deprecation first. Then later do major version bump with the removal.

I certainly agree that this is a valid principle for many situations when someone changes/removes functionality or expected input/output from a program. However, in this case, I would disagree, that it is beneficial to proceed this way. I shall be easily persuaded if you help me understand any positives of doing so but at this point, I can't see any possible user, that would appreciate it. While at the same time, there are many negatives that IMHO vastly outweigh it.

i think it is good to keep the routine even in case it's probably not needed. if you remove the code without previous warning, it may surprise people not in pleasant way. Trying to first inform them first is the usual practice so it should be hold in every case. Also, keeping the code somewhere a bit longer can hardly bring any harm. Removing it suddenly is what can break something.

Can we merge? I still think, that going through a deprecation period while retaining the functionality and then removing it afterward is unnecessary since prunerepo is used almost(?) exclusively by us, the --cleancopr parameter is certainly used only by us and I am even leaving the parameter there and print a user-friendly error message when someone accidentally uses it.

I have deprecated the --cleancopr param. Sorry for delay.

I think we shouldn't assume nobody else is using prunerepo when it is a public package.

This PR has been migrated to GitHub as a placeholder issue:
https://github.com/fedora-copr/prunerepo/issues/4