Likely timing of future Thunderbird Gecko builds

Magnus Melin mkmelin+mozilla at
Wed Apr 19 14:00:36 UTC 2017

On 19.4.2017 05:23, R Kent James wrote:
> On 4/18/2017 12:57 PM, Magnus Melin wrote:
>> There might be some more breakage around 57 when extension-only code can be 
>> removed
> "Some more breakage" as in all of our addons no longer work? What do you 
> think we are going to do at that point? We have three choices: 1) stop 
> supporting XUL addons, 2) convince Mozilla to NOT remove the code we need, 
> or 3) start building from a mozilla-central branch (or compile-time code 
> branches), as we have done in TB 38, TB 45, and TB 52 for the last two 
> years. I don't see 1) or 2) as viable, so 3) WILL happen. I really don't 
> understand why that is so controversial, to me it is just planning ahead for 
> an inevitable future. Thunderbird did not die when we started building TB 38 
> and TB 45 from mozilla branches, not will it end when we start building TB 
> 57 and greater from a mozilla branch at the point when maintaining 
> mozilla-central compatibility forces compromises we are not willing to make 
> (like abandoning XUL addons).
It's hard to say how much work it will be for us to keep extensions working. 
Not entirely trivial, but my assumption has been we'd fork that particular 
aspect of the current code ("move current add-ons manager to comm-central"). 
It's not like the XUL overlaying is going away anytime soon internally, this 
is just about the actual installation/provision procedure.

Just as context for people not closely involved: those branches you talk about 
have been branches branched of from the ESR release branches. Branches to 
which we have cherry-picked some changesets to mozilla-central code so that 
they would land sooner instead of having to wait on the release train. What 
you are talking about with a permanent branching from mozilla-central is 
*totally* different. If you have a permanent fork as tip you can't 
realistically expect to every get back in sync with trunk and you're therefore 
left to die. You could compare it to a space shot with planned re-entry as 
opposed to just going of for Jupiter with no plans to ever return. Yes, you 
will run out of supplies.

Re add-ons: we want to allow the old-style add-ons since we that's a greater 
benefit for us that being compatible with Chrome et al - but supporting 
add-ons can't be done at all costs. If it turns out that we can't support the 
old style ones that's really too bad, but it's no reason to sacrifice 
Thunderbird core. Looking at this in a perspective, add-ons are very niche. We 
only have around 10 add-ons that are are popular enough to have > 1% of user 
share. Not representative to this groups for sure, but that means the very 
vast majority of users would be happy without add-ons (lightning excluded).

> I don't believe that talk of how quickly Thunderbird will die when we 
> branch, nor hope that we will muddle through somehow, are particularly helpful.

I'd like to understand why you think it's helpful then. Add-ons support apart, 
what could you possibly win?

While I'm at it, let me just spell out what I'd imagine happens: after the 
branch is EOL for mozilla-central, you could potentially back-port security 
fixes for some months. After then all expectations could be way off - other 
code the back-ported changes didn't include could have changed so nothing 
applies, or if it applies, how it works could have changed behind your back. 
You'd have a system where nobody could tell you anything because X or Y didn't 
exist anymore or Z been invented yet. All this not even mentioning the 
man-power wasted to back-port stuff, while it could be used elsewhere. Support 
for new JavaScript features (which is moving quickly), all good-buy, there's 
no expectations you could even try to port those.


More information about the tb-planning mailing list