I think the run_on_change deprecation introduced in 3db6ee1 is too rude: It forces guard gem authors to either break backwards compatibility or force up-to-date users to read through (when in doubt multiple incarnations) of a 7-line deprecation warning.
I think the main motivation of the change was to make guard gem authors aware of the fact there's also run_on_additions and run_on_modifications to take care of, but in most situations guard gems are actually only interested in run_on_changes, for which run_on_change is an adequate alias in my opinion, and does not break the existing API in a manner that it needs to be extinguished ASAP. Also, this obviously hits more guard gem users than authors, so I think that the deprecation warning is a misplaced means of communication here.
In my opinion the docs for guard authors should point out to prefer run_on_changes over the singular version, but for the two reasons mentioned above I think the other one should be just as fine.
Also, in plenty of places the API docs still refer to run_on_change :)
Yep, I'm with Chris. Active maintainers have already changed their Guard plugins, all the others will probably never. So why bother Guard users with this deprecation warning?
I'm for either removing it completely or add a new option like --show-deprecations that plugin authors can explicit enable to check if their Guard plugin uses any deprecated API.
What do you think @guard/core-team?
I agree, +1 for --show-deprecations
Deprecations must be explicit enabled. (Closes #298)
Guard will not show any deprecation messages by default,
instead a plugin author has to explicit enable them by passing
`--show-deprecations` to Guard on startup.
Thanks @colszowka for speaking wisely. Guard 1.2.2 is out in the wild that contains the little patch to give back freedom to the many Guard users out there.
Cool guys, thanks for the quick update!