Bugzilla

For 102 ESR, nothing visible will be changed.

Sorry, my question was unclear,
it's about until when we support the current way, that means when to remove the backward compatibility, for example:
  * when to remove the shim that's going to be added by bug 1766761
  * when to apply bug 1758481 patch that removes the deprecated feature

If (a) is acceptable, those changes can be done before 110, so, for example, the following transition plan is possible (to be clear, just an example):
  * 102 - 105: rewrite in-tree code (during this cycles, "current" way is supported, and "new" way is partially supported)
  * 106 - 108: rewrite not-in-tree consumer (during this cycles, both "current" and "new" ways are supported)
  * 109: remove backward compatibility (after this cycle, only "new " way is supported)
and in that case, ESR will be:
  * 102: only "current" way is supported
  * 110: only "new" way is supported

If (b) is required, those changes need to be deferred until 111+ cycle.

For 102 ESR, nothing visible will be changed.

Sorry, my question was unclear,
it's about until when we support the current way, that means when to remove the backward compatibility, for example:
  * when to remove the shim that's going to be added by bug 1766761
  * when to apply bug 1758481 patch that removes the deprecated feature

If (a) is acceptable, those changes can be done before 110, so, for example, the following transition plan is possible (to be clear, just an example):
  * 102 - 105: rewrite in-tree code (during this cycles, "current" way is supported, and "new" way is partially supported)
  * 106 - 108: rewrite not-in-tree consumer (during this cycles, both "current" and "new" ways are supported)
  * 109: remove backward compatibility (after this cycle, only "new " way is supported)

and in that case, ESR will be:
  * 102: only "current" way is supported
  * 110: only "new" way is supported

If (b) is required, those changes need to be deferred until 111+ cycle.