Self-updating nightly builds counter-productive for testing
Hi,
I'm trying to test against Thunderbird 68. Given that there are beta
builds yet, not even a candidate, I hadto resort to finding the latest
nightly that is 68, and test with that. The first test worked. The
second failed.
On a second look, I noticed that I am using a TB 69. But I had installed
TB 68.
What happened? The auto-updater. It didn't ask me, it just immediately
updated on first start, without question (neither before download nor
before the install), and without waiting.
I specifically needed a TB 68. I also test with new profiles all the
time, so setting a preference isn't really a good solution.
I think this is not a special case. Any sort of binary testing,
regression test etc. would need to rely on the build being what I
actually installed. Diligent testing always happens in a new profile.
So, I expect a lot more testers to run into this issue.
Can I ask that we change the preference back to no automatic update? At
least not without asking? For people who continuously use Thunderbird
Nightly for their daily work, as "dogfood", they would typically use the
same profile. The auto-update is important only for continuous use.
Continuous users would also use the same profile, and they can answer
the question "do you want to update?" once.
OTOH, pure dedicated testers with fresh profiles need to rely on the
build being exactly what they installed. Thus, fresh profiles should
not auto-update not without asking.
On 11 Jun 2019 01:08, Ben Bucksch wrote:
I'm trying to test against Thunderbird 68. Given that there are beta
builds yet, not even a candidate, I hadto resort to finding the latest
nightly that is 68, and test with that. The first test worked. The
second failed.
You can always download a build from treeherder. Those builds have been
available since 22nd May, I've been using them in production since 26th
May without major problems. That's how a few regressions got reported
and fixed.
Draft release notes:
https://www-stage.thunderbird.net/en-US/thunderbird/68.0beta/releasenotes/
Jörg.
using tree herder build is a very good idea, thanks. I'll do that.
however, given that nightlies are archived a long time and are useful for regression testing, and you'd not want them to auto update (why else archive them?), do you think that my logic outlined below makes sense?
Am 11. Juni 2019 20:14:14 MESZ schrieb "Jörg Knobloch" jorgk@jorgk.com:
On 11 Jun 2019 01:08, Ben Bucksch wrote:
I'm trying to test against Thunderbird 68. Given that there are beta
builds yet, not even a candidate, I hadto resort to finding the
latest
nightly that is 68, and test with that. The first test worked. The
second failed.
You can always download a build from treeherder. Those builds have been
available since 22nd May, I've been using them in production since 26th
May without major problems. That's how a few regressions got reported
and fixed.
Draft release notes:
https://www-stage.thunderbird.net/en-US/thunderbird/68.0beta/releasenotes/
Jörg.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
--
Sent from my phone. Please excuse the brevity.
On 11 Jun 2019 22:56, Ben Bucksch wrote:
however, given that nightlies are archived a long time and are useful
for regression testing, and you'd not want them to auto update (why
else archive them?), do you think that my logic outlined below makes
sense?
The auto-update is a real pain, I agree. Today I did some regression
finding, and as soon as I looked at "About TB" is started auto-updating :-(
However, I think there is no pref you can flip, all you can do is set
the check interval to a year or so.
Further reading: https://bugzilla.mozilla.org/show_bug.cgi?id=1481589
and thread "[Maildev] Please make it easier to stick on a specific
nightly build" on this mailing list.
Jörg.
On Tue Jun 11 2019 14:14:14 GMT-0400 (Eastern Standard Time), Jörg
Knobloch jorgk@jorgk.com wrote:
You can always download a build from treeherder. Those builds have been
available since 22nd May, I've been using them in production since 26th
May without major problems. That's how a few regressions got reported
and fixed.
Draft release notes:
https://www-stage.thunderbird.net/en-US/thunderbird/68.0beta/releasenotes/
The link above is to the treeherder builds? I don't see anything about
treeherder on that page. Googling shows a lot of links, but I didn't see
anything about it other than this:
https://wiki.mozilla.org/EngineeringProductivity/Projects/Treeherder
Also - where can I read more about these builds? Do they not auto-update?
On 12 Jun 2019 15:40, Tanstaafl wrote:
Also - where can I read more about these builds? Do they not auto-update?
TB 68 beta is about to be released, so no need to get stuff from the
treeherder (https://treeherder.mozilla.org/#/jobs?repo=comm-beta).
You can get if from
http://ftp.mozilla.org/pub/thunderbird/candidates/68.0b1-candidates/build3/
or
http://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-beta/
which is not the latest, but never mind.
I think they auto-update to, but only to the next 68 beta version, so
you stay on 68 for your testing.
Jörg.
On 12-06-2019 00:14, Jörg Knobloch wrote:
On 11 Jun 2019 22:56, Ben Bucksch wrote:
however, given that nightlies are archived a long time and are useful
for regression testing, and you'd not want them to auto update (why
else archive them?), do you think that my logic outlined below makes
sense?
The auto-update is a real pain, I agree. Today I did some regression
finding, and as soon as I looked at "About TB" is started
auto-updating :-(
However, I think there is no pref you can flip, all you can do is set
the check interval to a year or so.
Further reading: https://bugzilla.mozilla.org/show_bug.cgi?id=1481589
and thread "[Maildev] Please make it easier to stick on a specific
nightly build" on this mailing list.
For testers who need it, what you can do to really prevent automatic
updates is to
- create a directory named distribution under the folder where
thunderbird is installed - in the distribution folder, add a file named policies.json, with
content as
{
"policies": {
"DisableAppUpdate": true
}
}
-Magnus