|There's more than one way to do things|
Re^4: Seeking your opinions on proposed patch to File::Utilby martell (Pilgrim)
|on Oct 01, 2012 at 19:47 UTC||Need Help??|
I think throwing a warning out for something that will change in a future release isn't good practise. I personally debug until all errors and warnings are gone. In some coding environments the code repository even tests this in an automated way before accepting a commit. Your warning will disrupt this. The closest thing I've seen before is a warning that you are using an experimental feature. And that is a different situation then you are facing.
If you are really worried about code disruption, then you should not change the behaviour of the switch --pattern and use a new switch e.g. --fileter-pattern. Put the new behaviour in the new switch and throw a warning on the old --pattern switch that it is depreciated. This is the only good way to change fundamentally a behaviour with the least possible disruption for coders. Old is old and new is new. Simpler is not possible.
If it is crucial for you to change the switch --pattern, then I think it is better to change the behaviour according following plan:
Step 1: Put up a big warning message in the documentation of the switch --pattern that the behaviour will change in the next release. Put the new behaviour already in on a different switch e.g. --filter-pattern so coders can already code according the new behaviour.
Step 2: The release after, you make the switch --pattern an alias of --filter-pattern. On top of that put the old behaviour in a new switch, e.g. --pattern-no-recursive and throw a warning on the use of this switch saying that it will be deprecated on future release x. In this way people can keep the old behaviour with a simple change in their code while the warning will remind them this must be changed.
Step 3: The release after, you remove the old behaviour and then, according taste, you could depreciate the switch --filter-pattern in future release by putting first a warning and then removing the switch.
You probably now feel why I think it is better to use a new switch if you are really serious about code disruption...
And at last, but maybe the biggest advise: whatever you do, put the changes clearly in your documentation of the switches!
Again, this is only my humble 2 cents.