Thunderbird 68.0 ESR release

[Óvári]

Hello,

The Thunderbird Beta channel lists Thunberbird 69.0b1
https://www.thunderbird.net/channel/
https://www.thunderbird.net/en-US/thunderbird/69.0beta/releasenotes/

Thunderbird 60.8.0 is listed at the main Thunderbird page.
https://www.thunderbird.net/

Can you please advise when Thunderbird 68.0 ESR will be listed at the main Thunderbird page?
https://www.thunderbird.net/

Thank you

Óvári

_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

[Jörg Knobloch]

On 27 Jul 2019 12:40, Óvári wrote:
> Can you please advise when Thunderbird 68.0 ESR will be listed at the
> main Thunderbird page?
> https://www.thunderbird.net/

Hasn't been released yet, ETA August 2019. Jörg.

[John Bieling]

Is there any Chance we Can roll back Beta to 68? For me it is very strange that we can no longer release Beta Versions for the 68 branch while preparing the release for 68 ESR.

Also testing addons is now complicated again.

Why is this happening?

Thanks for your time
John

[Jorg K (Android)]

The beta program for the 68 cycle has come to an end.

Sent with AquaMail for Android
http://www.aqua-mail.com

[Jorg K (Android)]

Oops, sent before I finished :-(

Yes, the 68 beta program has come to an end. TB 68 beta 5 will be released
as TB 68.0 ESR with some selected additional fixes, mostly UI corrections
which are being validated on 69 beta now.

Managing two beta versions concurrently is an absolute nightmare not to be
repeated. We ran the 60 beta program to beta 11 since versions 61 and 62
didn't have a working calendar due to the discontinuation of XUL addons and
the M-C overlay loader.

Fortunately now we are in a much better position with a working 69 beta. So
we will conduct releases as with all other versions except 60.

Sent with AquaMail for Android
http://www.aqua-mail.com

On July 27, 2019 6:00:59 PM "Jorg K (Android)" <jo...@jorgk.com> wrote:

> The beta program for the 68 cycle has come to an end.

[Axel Grude]

One major problem is that the beta auto-updates to 69 and can make the profile un-roll-backable. That's not a good experience for early adopters.

It's also a fairly big problem for Add-on developers; auto update has to be absolutely disabled to avoid having to recreate profiles to get the debugger back. Seeing that there willbe more breaking changes in the future, wouldn't it be better to not auto-update betas to when incrementing major version numbers and keep these tracks separate?

Axel

Axel Grude
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips

Subject:Re: Thunderbird 68.0 ESR release
From:Jorg K (Android) <jo...@jorgk.com>
To:Thunderbird Planning (Moderated) <tb-pl...@mozilla.org>
Sent: Saturday, 7/27/2019, 17:16 17:16 GMT DT +0100 [Week 30]

[Jörg Knobloch]

On 27 Jul 2019 23:23, Axel Grude wrote:
>
> One major problem is that the beta auto-updates to 69 and can make the
> profile un-roll-backable. That's not a good experience for early
> adopters.
>
> It's also a fairly big problem for Add-on developers; auto update has
> to be absolutely disabled to avoid having to recreate profiles to get
> the debugger back. Seeing that there willbe more breaking changes in
> the future, wouldn't it be better to not auto-update betas to when
> incrementing major version numbers and keep these tracks separate?
>

For add-on testing of a TB 68 version that won't auto-update, I suggest
to use an unofficial pre-release of TB 68 ESR from treeherder:

Linux64:
https://queue.taskcluster.net/v1/task/eC0baia9RoKXLCeA8fS4xQ/runs/1/artifacts/public/build/target.tar.bz2

Mac:
https://queue.taskcluster.net/v1/task/bjU4LAerSRGSGdSS-LnmRA/runs/0/artifacts/public/build/target.dmg

Windows x64:
https://queue.taskcluster.net/v1/task/YpMW1iR5QtGbh0DrLz4y1w/runs/0/artifacts/public/build/install/sea/target.installer.exe

Due to a bug, these binaries announce themselves as TB 68.0b5, but
they're not.

You might run into one of these issues, most of which will be fixed in
the final release: https://mzl.la/2YrH7we

We're currently working on clearing some administrative hurdles, like
l10n sign-off and defining the release process better, before we can
build the release.

Jörg.

[John Bieling]

Thanks for your answer. There is one thing I have not understood: Why was a Beta 69 released? Why didn’t we do the final UI stuff in another 68 Beta?

Are we forced by some time table to release beta 69 now? We postponed the release of ESR, why can’t we postpone beta 69?

For me it is just strange, that the beta program for 68 ends, before 68 ESR is released.

There have been changes from 68 to 69, so addons for 68 have no official test target anymore.

Thanks for your time,
John

[Jacques Angevelle]

Hi,

There was a lot of messages about add-on compatibility. When 68.0 will
be released what can be done to avoid a lot of disabled add-ons ? Last
message about extension statistics shows a majority will be disabled if
I understand well (208 including lightning are reported not compatible
with TB 68.0).

Jacques

[op...@optosolar.com]

Is there a 32 bit version for testing?
My notebook only has 32 GB for C drive, so it is 32 bit as that takes less harddisk space.

[Wayne Mery]

If you read between the lines Jorg pretty much already answered this, as to why we continued cranking out v60 beta.  To restate and also add :

* calendar was  not ready for v61 and there was no point doing a beta without calendar

* v60 add-ons situation initially was horrible - not so here with v68 (although it is not ideal for reasons you and others have stated - but the fact is updated add-ons always lag in the initial release)

* IIRC efail patches were still being developed for v60

* messaging around add-ons was started much earlier for 68, and we've already done an extended period of v68 betas (almost a month) which have benefited add-on developers

* not doing Beta 61 and 62 code did have some negative side effects

In summary, in version 68 we are in much better position both in terms of code quality and add-on availability compared to v60.  This tips the decision in favor of moving forward with new beta versions. and not continuing 68 betas.

[Mark Banner]

On 28/07/2019 10:41, Wayne Mery wrote:

> In summary, in version 68 we are in much better position both in terms
> of code quality and add-on availability compared to v60.  This tips
> the decision in favor of moving forward with new beta versions. and
> not continuing 68 betas.

I think it might still have been useful not to release 69 beta until 68
had been released. This would have a) made it easier for extension
authors to continue their testing & fixing without having to tweak
prefs, or find versions to download, b) meant that there's still beta
users using the same version that is going to be released and hence can
give extension authors feedback as to any issues.

The current risk is that there's something in 69 that is different to 68
which could break add-ons again, making it hard for authors to know that
they've got a stable release.

Obviously, we can't change it this time, but something to consider for
future.

Mark

[Jörg Knobloch]

On 27 Jul 2019 20:18, John Bieling wrote:

Thanks for your answer. There is one thing I have not understood: Why was a Beta 69 released? Why didn’t we do the final UI stuff in another 68 Beta? 

Are we forced by some time table to release beta 69 now? We postponed the release of ESR, why can’t we postpone beta 69?

For me it is just strange, that the beta program for 68 ends, before 68 ESR is released.

I missed this post, so here a late reply.

My ideal would have been to ship TB 68 beta 5 followed by TB 68 ESR. Wayne pointed out that's it's wise to have some working beta available before the ESR is shipped, so in case the ESR goes badly wrong, we have a platform to get fixes to a larger audience before shipping them in an ESR version.

Since

1. we are already in the 70 cycle, so at 69 beta,
2. managing two betas is a nightmare,
3. 69 beta is fully functional, even it if doesn't have a lot of new stuff

we decided to go for beta 69. And we don't know its working and not stuck with releng issues until we really ship it. That TB 68 ESR was then delayed for the administrative reasons, like l10n stuff, is unfortunate; the plan was to release it soon after TB 69 beta. Now it will be at least a week later.

For users it's not really a problem. Those on the beta channel will go to 69 and those on the ESR channel will only see TB 68 ESR at 68.1. And the highly skilled add-on authors can make sure they have some sort of 68 version for a little while ;-) - Can't you just deny updates on TB 68 beta?

Jörg.

[Wayne Mery]

On 7/28/2019 4:00 PM, Mark Banner wrote:

On 28/07/2019 10:41, Wayne Mery wrote:

In summary, in version 68 we are in much better position both in terms of code quality and add-on availability compared to v60.  This tips the decision in favor of moving forward with new beta versions. and not continuing 68 betas.

I think it might still have been useful not to release 69 beta until 68 had been released. This would have a) made it easier for extension authors to continue their testing & fixing without having to tweak prefs, or find versions to download, b) meant that there's still beta users using the same version that is going to be released and hence can give extension authors feedback as to any issues.

The current risk is that there's something in 69 that is different to 68 which could break add-ons again, making it hard for authors to know that they've got a stable release.

Obviously, we can't change it this time, but something to consider for future.

Mark

It's a very good point and we will face the same choice come version 76.  Perhaps by then we can have our cake and eat it too.

What we discussed for 68 was somehow having a channel that stayed "beta" version 68, or a pre-release channel where longish testing could occur. But time and resources were short, plus we had no mechanism in place to split the user population. And so that idea didn't happen for 68. 

If anyone knows *exactly* the internals of building and using channels, and a detailed plan of making something like this work (a split N and N+1 beta) within the mozilla build infra, I'm sure r...@thunderbird.net and other drivers would be interested in hearing the details.

[John Bieling]

+1

Please consider this, the current practice causes lots of issues.

John

> Am 28.07.2019 um 22:00 schrieb Mark Banner <mba...@mozilla.com>:
>
> I think it might still have been useful not to release 69 beta until 68 had been released. This would have a) made it easier for extension authors to continue their testing & fixing without having to tweak prefs, or find versions to download, b) meant that there's still beta users using the same version that is going to be released and hence can give extension authors feedback as to any issues.
>
> The current risk is that there's something in 69 that is different to 68 which could break add-ons again, making it hard for authors to know that they've got a stable release.
>
> Obviously, we can't change it this time, but something to consider for future.

[Rob Lemley]

The simple idea I had was to create a rule on the beta channel similar to what is going onto release. If you are running 69 beta, you would receive newer versions such as 69.0beta2 and 70.0beta1, etc. But if you had 68.0betaX you would only receive any additional 68 betas. The trick is to match against versions in Balrog and if someone wanted the newer betas they would have to download and install manually first.  Once 68.0 releases off the esr68 repo, those extra rules could go away.

But as Wayne suggests, it's a little late for that now.

_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

-- 
Rob Lemley
Thunderbird Build Engineer
r...@thunderbird.net - :rjl

[op...@optosolar.com]

As a matter of fact, updating beta is safe if TB beta is set not to automatically do updates.

After some while of TB being open, 68b4 announced there is an update.
After accepting, it updated to 68b5 (not 69b).

This is how it stayed. Help-> about offers the 69b1 download buttion, but it is the user's choice whether to accept or not.

As consequence, a new channel is not really needed, but rather more information how to appropriately setup the beta channel.
That should go here: https://www.thunderbird.net/en-US/channel/ and should include a warning that the profile manager will show profiles of old version and new beta version. If one erroneously chooses the old profile, it will be auto-updated to beta and no way back is possible (well it seems from other posts here that it might be possible for the technically very adapt - but a warning definitely is warranted).

Also, there should go some info where to install a beta. Can it be in the same user profile as the production TB, might it kill the production accounts if it goes there, etc.

The link given for installation in beta pages point to a document that is called outdated and does not give any advice on beta installation.

Currently, the beta download pages gives no information except the download button. As there is/maybe a risk of killing of the production TB profile, more info should go there.

The release notes page https://www.thunderbird.net/en-US/thunderbird/69.0beta/releasenotes/ has buttons for install information but they do not give any information on the questions given above.

[Christian Riechers]

On 7/28/19 12:13 AM, J??rg Knobloch wrote:
> You might run into one of these issues, most of which will be fixed in
> the final release: https://mzl.la/2YrH7we

Is there any chance to still get bug 1526765 fixed for the TB68 release?
https://bugzilla.mozilla.org/show_bug.cgi?id=1526765

[Joachim Herb]

> The current risk is that there's something in 69 that is different to
> 68
> which could break add-ons again, making it hard for authors to know
> that
> they've got a stable release.
>
> Obviously, we can't change it this time, but something to consider for
> future.

I can confirm this problem. In Thunderbird 69, the customization of the
header toolbar is broken
(https://bugzilla.mozilla.org/show_bug.cgi?id=1556261). And this breaks
my addon Compactheader. So in the moment the only possibility to test
it, is to use the treeherder builds of the comm-esr68 branch
(https://treeherder.mozilla.org/#/jobs?repo=comm-esr68). But the users,
who are on the beta branch of Thunderbird and have downloaded the
lastest version of the addon from ATN will now have a broken version of
the addon.

An again, there is no more beta channel on ATN, so I cannot post a
simple fix for it there.

This is certainly not a good situation.

Joachim

[Jörg Knobloch]

On 27 Jul 2019 13:25, Jörg Knobloch wrote:

On 27 Jul 2019 12:40, Óvári wrote:

Can you please advise when Thunderbird 68.0 ESR will be listed at the main Thunderbird page?
https://www.thunderbird.net/

Hasn't been released yet, ETA August 2019. Jörg.

All those who want to do add-on testing can get a pre-release version here now:

http://ftp.mozilla.org/pub/thunderbird/candidates/68.0-candidates/build2/

Language packs: http://ftp.mozilla.org/pub/thunderbird/candidates/68.0-candidates/build2/win64/xpi/

Enjoy!

Jörg.

[Walter L Schwartz]

Seems to be missing a en-US build for 64-bit Linux. :-(

[Jörg Knobloch]

Oh boy, what happened there. There are en-US builds for Windows, Mac and Linux32, but not Linux64 :-(

Rob, can you please take a look.

Jörg.

[Rob Lemley]

Will be fixed for the next build.