Remove jqLite#bind & jqLite#unbind

[mgol]

Note: for support questions, please use one of these channels: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#question. This repository's issues are reserved for feature requests and bug reports.

Do you want to request a feature or report a bug?
A refactor (removing a feature).

What is the current behavior?
jqLite#bind & jqLite#unbind exist and are aliases to jqLite#on & jqLite#off respectively.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).
N/A

What is the expected behavior?
jqLite#bind & jqLite#unbind should be removed.

What is the motivation / use case for changing the behavior?
Those methods will be deprecated in 1.6.0 so we should remove them in 1.7.0.

Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.
N/A

Other information (e.g. stacktraces, related issues, suggestions how to fix)
N/A

[dcherman]

@mgol Why plan for removal at all? It seems like a potentially big breaking change in order to save 2 lines of code that don't introduce significant complexity, and it doesn't align with jQuery's goals of deprecation without removal for event shorthands/aliases (as you definitely know)

[gkalpak]

We have recently decided that deprecated features should generally stay in the code for one minor release and be removed in the next minor (breaking) release. And that we should create issues with an appropriate milestone as a reminder.

This is not a hard rule; we can discuss it when the time comes for 1.7.0.

Admittedly, bind/unbind are kind of special, since they are just alises. On the other hand, migrating is pretty easy, so I don't see much benefit in allowing people use a method that has been deprecated for a long time. (Just my 2 cents.)

In any case, thx for raising this @dcherman so we can take it into account when the time comes 😃

[mgol]

Thanks @dcherman for the comment.

@gkalpak It's true it's easy to change the code but this applies to your code only. jQuery has a large ecosystem of plugins, not all of which are regularly updated, especially as long as jQuery doesn't remove a particular deprecated API.

Maybe we should treat jqLite-related deprecations differently than for the rest of Angular: wait for removal in jQuery before removing the API in Angular itself?

[gkalpak]

Maybe we should treat jqLite-related deprecations differently than for the rest of Angular: wait for removal in jQuery before removing the API in Angular itself?

Makes sense.

[mgol]

We've decided to follow this strategy:

we should treat jqLite-related deprecations differently than for the rest of Angular: wait for removal in jQuery before removing the API in Angular itself

We'll document it in FAQ.

I'm closing this ticket; thanks, @dcherman!