Handle the need to change the @api annotated classes/interfaces

Actually the way we wrote our backwards compatibility policy was centered on that promise for client users of that interface not implementors. During our market research we heard from a # of community members that majority will be using plugins on interfaces to customize behavior and would likely avoid creating an implementation of an interface* ( exceptions being shipping, payments and search adapters where it makes more sense to be an implementor of the interface(s)).

Having said that internally we're doing as much as possible to limit disruptions; communicate ahead of time future disruptions/etc.

Some suggestions to minimize disruptions (based on our market research and what we're doing internally):

• Q4 is least disruptive time to make wide spread 'breaking change'; if communicate ahead of time to the community/ecosystem ( 3 months ahead if possible ). This is a good time period for sweeping changes/breaking changes
• Try using extensible objects rather then adding methods; this isn't disruptive to an implementor of the interface
• If you've created an interface that's more likely to be implemented by others; try to keep it as stable as possible/at most change 1 per year with lots of warning ( cough alternatively introduce new interfaces using our declared function syntax that we're introducing in 2.1 to add new functionality; basically that's how we support global synonyms in 2.1 for MySQL & Elastic but not for Solr adapters. We'll use that pattern go forward where it makes sense ).
• Communicate, Communicate, Communicate :)