guard/guard — pull request #647 by e2 (2014-11-03 21:26:07+00:00)
Title: Reactivate deprecations ... because reasons!

It's been 2 years since https://github.com/guard/guard/issues/298, so it's about time to revisit.

Why:
- breaks semver rules (since you can't remove api changes without at least one version showing deprecations)
- they don't prevent anything from working
- using an environment variable is so ridiculously convenient, there's no reason to hide them by default
- the fact that there's an option for it - it just takes up space in the code and README
- they don't work, since Guard::UI is sometimes not set up properly - so deprecations either crash or don't show
- there's no way to enable them e.g. when doing `guard init`
- even guard silently still uses it's own deprecated methods...
- with guard 3.x, deprecations are going to be essential for development and backward compatibility with current plugins
- a new API can be developed based on use cases, so many plugins may become simpler as a result, while having method signatures that can stay the same while withstanding more changes
- without deprecations, we can't even warn about obscure behaviors that can change as a result of internal refactoring or bugfixes