<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>A few clarifications:</p>
    <p>The changes are for the general public only going to come into
      effect in the next ESR release, Thunderbird 78 in mid 2020. For
      developers, in beta and nightly support will start to disappear
      from core once we're ready do so, probably during 2019. Some
      notable things that will be removed are the custom overlay loader
      (Overlays.jsm), and support for add-ons requiring restart.<br>
    </p>
    <p>For add-on authors going forwards, there is of course also an
      option C (depending on what the add-on does): work with us to
      integrate the functionality into core. If the add-on is under the
      bug-fix category this is certainly the way to go as no API for a
      bug-fix would be in sight. In general we're happy to include
      functionality provided it's of general usefulness. <br>
    </p>
    <p>MailExtension Experiments is one way to go (and that's not
      deprecated), but should not be seen as a long term solution. It
      may be a short term solution though. It means you need to follow
      changes closely and things will often break. Sometimes in ways
      that could be hard to solve. They simply need to be understood to
      be seen as experiments, with no warranties.</p>
    <p> -Magnus<br>
    </p>
    <div class="moz-cite-prefix">On 01-10-2019 16:02, Magnus Melin
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:2bb9a19f-904c-e50c-33f1-eecabcc8b860@iki.fi">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Since version 57, Firefox only supports add-ons through the
        WebExtensions APIs. At the time, Thunderbird decided to continue
        supporting traditional add-ons, since we hadn't yet been able to
        develop replacing APIs for add-on developers to use. <br>
      </p>
      <p>Since then, Thunderbird has been developing WebExtensions APIs
        (aka MailExtensions), and the number of APIs available is
        continuously growing: <a class="moz-txt-link-freetext"
          href="https://thunderbird-webextensions.readthedocs.io/"
          moz-do-not-send="true">https://thunderbird-webextensions.readthedocs.io/</a><br>
      </p>
      <p>Because the toolkit support for traditional add-ons has been
        largely removed, this has meant a lot of work for Thunderbird to
        keep things going for add-ons. For the server side it has also
        meant a lot of extra work (addons.thunderbird.net is a fork of
        addons.mozilla.org). Add-on developers haven't had an easy ride
        either: The number of changes to make an add-on compatible has
        been significant. <br>
      </p>
      <p>Going forwards we want to change this. Support for traditional
        add-ons is going to be dropped as soon as we're ready to do so
        internally. There are a few pieces of code that we need to
        convert over internally: <br>
      </p>
      <ul>
        <li>Lightning: to be integrated into the code base<br>
        </li>
        <li>Mozmill (used in our test infra): we're converting over to
          using mochitests instead</li>
      </ul>
      It's not yet clear exactly when we're ready to rip out the support
      for traditional add-ons from the code base, but it should be
      whitin the Thunderbird 72 time frame - so by end of 2019. The next
      major version of Thunderbird, version 78, will be out around June
      2020. Up until then, code wise many things are going to change.
      For instance, what is left of XUL will be gradually going away,
      and documents will shifted to being XHTML with a less and less XUL
      flavor. <br>
      <p>Dropping support for non-MailExtension add-ons is also needed
        for addons.thunderbird.net. Supporting old-style add-ons would
        require a significant investment in the back-end there, since
        the Django version of the back-end would reach EOL and have to
        go through a painful and expensive upgrade.</p>
      <p>As an author of a traditional add-on, what should you do? There
        are two routes: A) convert your add-on to a MailExtension. If
        the API you need doesn't exist yet, <a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=Add-ons:%20Extensions%20API">tell
          us about it</a>. B) convert your add-on to a <a
          moz-do-not-send="true"
href="https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html">Web
          Extension Experiment</a>. Most add-ons should be able to be
        converted to an experiment with a reasonable effort. The
        recommended path is forward is to convert it to an a
        MailExtension though. That will make sure the add-on works
        without significant changes over many years. If you go with
        option B, you'll have to maintain a lot of more code yourself
        and breakages can and will be bad unless you keep up really
        close. MailExtension Experiments should be seen as such,
        experiments with the goal of getting the API they need into
        Thunderbird core. Please work with us on getting the needed
        pieces in as a supported API. Initially we'll be allowing
        experiments to be exposed to the general public, but over time
        (years) Thunderbird will gravitate towards not having the
        experiments available to the general public, the same way it
        works for Firefox.<br>
      </p>
      <p> -Magnus<br>
      </p>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
    </blockquote>
  </body>
</html>