<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I don't see how that would work... for that case it seems more
      reasonable to keep developing it as an add-on (experiment or not)
      and make sure the add-on users are paying or donating enough to
      the add-on to keep development of it sustainable.</p>
    <p> -Magnus<br>
    </p>
    <div class="moz-cite-prefix">On 16-10-2019 15:03, Axel Grude wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:d0d9c00b-8532-8da5-6862-16535efcd717@gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div id="smartTemplate4-template">
        <p>Dear Magnus,</p>
        <p> </p>
        <blockquote type="cite">or 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.
        </blockquote>
        I actually thought about this myself - if it means not losing
        the "privileged access" to the JavaScript / XPCOM layer it may
        mean a lot less work than constantly adapting an Add-on. There
        is only one problem - over the 10 years I am working4 on this
        project I have managed to turn it into a paid / self-employed
        thing, and with the amount of work ahead and to maintain the
        functionality, the only way to recoup would be to turn into a
        Thunderbird employee. <br>
        <p>I am not sure if that's the correct way forward for me -
          would it possible to imagine a specialized / subcontractor
          position for an Add-ons developer so they can focus on just
          that specific work / functionality, rather than being deployed
          into stuff we may not be interested in? <br>
        </p>
        <p>The other argument against core is that only a small group of
          users may be interested in the functionality of these legacy
          extensions, and by rights <i><b>they </b></i>should be the
          ones funding that. A "Thunderbird advanced" / freemium model
          might be a way out here. Just brain storming...<br>
        </p>
        <p>Axel</p>
        <style type="text/css">.myName {
  text-shadow: 1px 1px 2px #DDD; 
  transition:font-size 0.5s;
}
.myName:hover, .myName a:hover 
{ font-size:13pt; text-shadow: 3px 3px 4px rgba(200,250,200,0.7);}
.moz-signature {opacity: 1.0 !important;}
.myName a { cursor: pointer !important; transition:font-size 0.5s;}
.myLogo {
  transition: all .4s ease-out;
}

.myLogo:hover {
  transform: scale(3) translate(-30px,-5px);
}
#mySignature, :not(blockquote) #mySignature {
  background: rgb(230,240,163); 
  background-image: linear-gradient(to bottom, rgba(230,240,163,1) 0%,rgba(210,230,56,1) 50%,rgba(195,216,37,1) 51%,rgba(219,240,67,1) 100%);
  color: #444; 
  box-shadow: 4px 4px 9px -2px rgba(0,0,0,0.65); 
  border-radius: 0.7em; padding: 0.8em 1.2em; 
  border: 1px dashed #8080A0; 
  font-size: 11pt !important;
  font-family: 'Lucida Sans Unicode', 'Lucida Grande', sans-serif; 
  width: 65%; 
}
.AddonList a {
  color: #666666; 
  font-size: 10pt !important;
}
</style>
        <div id="mySignature"> <b class="myName"><a
              href="mailto:axel.grude@gmail.com" moz-do-not-send="true">Axel
              Grude</a></b> <br>
          Music Production and Composition <br>
          Thunderbird Add-ons Developer <span class="AddonList">(<a
href="https://addons.thunderbird.net/thunderbird/addon/quickfolders-tabbed-folders/"
              moz-do-not-send="true">QuickFolders</a>, <a
              href="https://addons.thunderbird.net/thunderbird/addon/quickfilters/"
              moz-do-not-send="true">quickFilters</a>, <a
              href="https://addons.mozilla.org/firefox/addon/quickpasswords/"
              moz-do-not-send="true">QuickPasswords</a>, <a
              href="https://addons.thunderbird.net/thunderbird/addon/zombie-keys/"
              moz-do-not-send="true">Zombie Keys</a>, <a
              href="https://addons.thunderbird.net/thunderbird/addon/smarttemplate4/"
              moz-do-not-send="true">SmartTemplate⁴</a>)</span> <br>
          Visit my <a href="https://www.youtube.com/c/thunderbirddaily"
            moz-do-not-send="true">YouTube Channel</a> for email
          productivity tips <img style="margin-top: 1em; float: right;
            box-shadow: 1px 1px 2px rgba(20, 20, 20, 0.4);"
            moz-do-not-send="false" class="myLogo"
            src="cid:part8.3CC20B0B.DD44DBA7@iki.fi" alt="Get
            Thunderbird!" width="94" height="15"> </div>
      </div>
      <div id="smartTemplate4-quoteHeader">
        <style type="text/css" scoped="">
#newHeaderAG1 b { font-weight:bold; color: #990033; min-width: 4.5em; max-width:none; display:inline-block;}
</style>
        <blockquote type="cite" style="margin-bottom: -20px !important;
          padding-bottom:20px !important;">
          <div id="newHeaderAG1" style="font-size: x-small; padding:1em;
            background-color:rgba(220,220,240,0.4); border-radius:3px;">
            <b>Subject:</b>Re: Intent to de-support: traditional add-ons<br>
            <b>From:</b>Magnus Melin <a class="moz-txt-link-rfc2396E"
              href="mailto:mkmelin+mozilla@iki.fi"
              moz-do-not-send="true"><mkmelin+mozilla@iki.fi></a><br>
            <b>To:</b><a class="moz-txt-link-rfc2396E"
              href="mailto:tb-planning@mozilla.org"
              moz-do-not-send="true"><tb-planning@mozilla.org></a>
            <br>
            <b>Sent: </b>Tuesday, 10/15/2019, 11:19 11:19 IST +0100
            [Week 42]<br>
          </div>
        </blockquote>
      </div>
      <blockquote type="cite"
        cite="mid:96f3cb1a-8052-2f76-3211-e54998c85d28@iki.fi">
        <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">
          <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" moz-do-not-send="true">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning" moz-do-not-send="true">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
        </blockquote>
        <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" moz-do-not-send="true">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning" moz-do-not-send="true">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
      </blockquote>
      <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>