Summary:

As Moodle leans more and more onto JS we need to decide how we handle the removal of old JS whether that is now unused functions / variables or entire modules.

In my experience we have just removed unused JS (functions, variables and whole modules) however, we should have some discussion around this.

Strategies

I can see a couple of ways to handle this.

1. Status quo
   1. Any JS can be removed at the discretion of the Developer, Peer reviewer & Integrator in a joint agreement (With no stubs remaining)
2. The mixed strategy
   1. Anything that is 'Public facing' could have a deprecation policy applied
   2. Anything internal to a module can be removed as long as the behaviour is replicated or managed 
3. The full deal
   1. Any and all JS should face the same / similar deprecation policy we apply to PHP

Any of the above strategies would most likely require a new deprecation module to handle the warnings to a developer i.e. alerts, console logs, throwing behat errors or plain throwing errors to the page (Could break the pages' JS however)

Responsibilities during upgrades:

As with the different approaches above there would essentially different responsibilities during upgrades

Approach 1: places the onus onto any 3rd party developers to ensure and core JS functions they may be using still exists during the upgrade process

Approach 2: states that any third party developer can not & should not directly call any functions situated within /local this however can not be enforced by us however, If a 3rd party were to use a 'Public' JS function then they'd be warned that it was being deprecated

Approach 3: gives the largest amount of backwards compatibility but also leads to bloat and dead ends within our JS

Other thoughts:

I am still a little unsure on which approach we should take but I feel that the third approach would lead us to a similar place that our current PHP deprecation process has taken us which can be cumbersome at the best of times and painful in the worst.