yui/yui3 — pull request #1560 by andrewnicols (2014-01-16 15:16:47+00:00)
Title: Convert Y.log to Y.message for deprecations

When we recently upgraded to 3.13, we had a couple of people experiencing issues in code which was still using Y.get instead of Y.one, as Y.get was recently removed (these were predominantly gallery modules).

These deprecations hadn't been picked up earlier because when developing, we typically run with a config such that:
* the group representing our modules has a filter setting of 'debug'
* core YUI has a filter setting of 'raw'

This means that we can debug our modules complete with all debugging messages, and can still trace through core YUI code where required, without being inundated with messages from core YUI which are less relevant to us. I suspect that we are not alone in this way of developing with YUI.

# Proposed solutions

I can see two reasonable ways forward which would help developers pick up deprecation notices whilst still seeing the wood through the trees and not have all core YUI debug messages. These possible solutions are discussed below.

## Change all deprecation warnings from Y.log to Y.message
Shifter has a regex which is designed to remove Y.log, but not Y.message.
For most people, changing to use this will be sufficient for this purpose and will mean that deprecation notices are more readily visible.
For production use, setting Y.config.debug to false will remove these too.

## Introduce a new Y.deprecated and us this instead of Y.log
This would also not be removed by Shifter and would operate almost identically to the Y.message solution. The difference being that it would be possible to introduce a new property in Y.config, similar to the debug property, but specifically aimed at deprecation warnings. This would allow them to be separated out from standard messages.

Having given it some thought, I suspect that using Y.message would be sufficient for a majority of cases and I can't really think of any reason you'd want one, but not the other.