Open Bug 1321131 Opened 4 years ago Updated 4 years ago

All SeaMonkey dev builds are on "default" release channel

Categories

(SeaMonkey :: Release Engineering, defect)

SeaMonkey 2.50 Branch
All
Windows
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: onnebula9, Unassigned, NeedInfo)

Details

(Keywords: reproducible)

To reproduce:

1. Download/build any developer build of SeaMonkey (i.e., nightly, beta, aurora)
2. Go to about:config and check "app.update.channel", or go to about: and see the release channel is "default".

For these non-release builds, the release channel should be set to a proper release channel. When new non-release builds are put up, SeaMonkey does not notify the user since it is still set to the default release channel.

I have found this to be the case on all platforms, and all development builds I've tested (from 2.40 up)

This is NOT a duplicate of #893547, since that bug relates merely not to the actual release channel, but merely the correct display thereof. The release channel here is correctly displayed, but erroneously set.
(In reply to neb9 from comment #0)
Can you contribute a source concerning function of "app.update.channel"?
Flags: needinfo?(onnebula9)
(In reply to neb9 from comment #0)
Effect is  REPRODUCIBLE with Server-Installation of  unofficial (by FRG) en-US SeaMonkey 2.50a1 (NT 6.1; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0 Build 20161127221846  (Default Classic Theme) on German WIN7 64bit: "app.update.channel" is "release" also in a newly created User Profile. 

And if I understand <http://kb.mozillazine.org/App.update.channel> correctly this indeed is wrong.

I will do some more investigation
Keywords: reproducible
a) FF 53.0a1 (2016-11-18) (32-bit) correctly shows "nightly" in "app.update.channel"
b) also Thunderbird Daily 53.0a1 (2016-11-27) (64-bit) correctly shows "nightly"

@neb9
Do you know where this started?

@Edmund:
Your area?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: Trunk → SeaMonkey 2.50 Branch
Unofficial/test builds are supposed to always have the "default" channel. That is the correct setting. Only official builds can have other channels, it's only useful for build that actually have updates delivered through the update servers.
From all I can see, there is no bug there.
(In reply to Robert Kaiser from comment #5)
> Unofficial/test builds are supposed to always have the "default" channel.
> That is the correct setting. Only official builds can have other channels,
> it's only useful for build that actually have updates delivered through the
> update servers.
> From all I can see, there is no bug there.

This applies not only to self-made builds, but also to the official (or as official as official gets) nightly, beta and aurora builds released on ftp.moz. So I'd still consider it a bug.
(In reply to neb9 from comment #6)
> This applies not only to self-made builds, but also to the official (or as
> official as official gets) nightly, beta and aurora builds released on
> ftp.moz. So I'd still consider it a bug.

OK, in terms of official, non-contributed builds, if the channel there is set to "default", that is definitely a bug, and ewong/Callek need to take a look.
> Effect is  REPRODUCIBLE with Server-Installation of  unofficial (by FRG) en-US SeaMonkey 

Rainer I am lazy and use the same config for all trees. So it will always be release in the builds I give you for testing (yes I know I shouldn't do this<g>).

It seems that MOZ_UPDATE_CHANNEL is currently not set in the trees or mozconfigs. Probably set for Firefox somewhere but i don't see where right now.
I just downloaded (on Linux-i686) both nightly (2.50) and aurora (2.49) builds.

Both display in app.update.channel nightly (for 2.50) and aurora (for 2.49) and
ditto with about:

Am I missing some step here?

I got both:

https://archive.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/seamonkey-2.50a1.en-US.linux-i686.tar.bz2

https://archive.mozilla.org/pub/seamonkey/nightly/latest-comm-aurora/seamonkey-2.49a2.en-US.linux-i686.tar.bz2
I believe this is limited to the Windows platform which means it's my bad.

I've made some infra adjustments and it should be fixed in 2.50a1 and 2.49a2.
OS: All → Windows
You need to log in before you can comment on or make changes to this bug.