Closed Bug 1445672 Opened 3 years ago Closed 3 years ago

Download link points to Beta instead of Stable release


(Release Engineering :: Release Automation: Other, defect, P1)



(firefox-esr52 unaffected, firefox59 unaffected, firefox60blocking fixed, firefox61 fixed)

Tracking Status
firefox-esr52 --- unaffected
firefox59 --- unaffected
firefox60 blocking fixed
firefox61 --- fixed


(Reporter: lidel, Assigned: jlorenzo)



(Whiteboard: [releaseduty])


(2 files, 1 obsolete file)

I've read but I am unable to download Firefox 59. Website keeps offering me latest beta (60b3) instead.
Tested on Linux and Mac, under Firefox and Chrome.

# How to replicate

1. open (or
2. click on "Download now" 
3. firefox-60.0b3.tar.bz2 (beta) will be returned instead of Stable (59)

# Expected behaviour

firefox-59.tar.bz2 (latest stable) should be returned instead.

# additional diagnostics

Impacted pages:

"Download now" button on these pages use the same link to

$ curl -sIL '' | grep Location                                                                                                                130 ~/local/opt/firefox

I can confirm this
Severity: major → critical
Ever confirmed: true
Component: Bedrock → Bouncer
Product: → Webtools
Version: Production → other
This should now be fixed. Please confirm.
Looks like this is misconfiguration in our release automation - when Beta shipped we updated the release aliases instead of the beta ones. It's being fixed right now.
Component: Bouncer → Release Automation
Priority: -- → P1
Product: Webtools → Release Engineering
QA Contact: catlee
I think this is a problem with and/or -- we don't make any distinction between "beta" and "release" when deciding which bouncer product to update. We'll try to get this fixed before 60.0b4 starts.
Assignee: nobody → jlorenzo
Whiteboard: [releaseduty]
Comment on attachment 8958915 [details] [diff] [review]
[build/braindump] Unset release_type when not rc r=aki

Hm, do we want `None` or `null` or `release_type: ` ?
I'm good with whichever one works, maybe they all do :)
Attachment #8958915 - Flags: review?(aki) → review+
Comment on attachment 8958917 [details]
Bug 1445672 - Do not rely on release-type to define alias name

Thank you!

::: taskcluster/ci/release-bouncer-aliases/kind.yml:53
(Diff revision 1)
> -      bouncer-products: ['apk']
> +      bouncer-products-per-alias:
> +         by-project:
> +            mozilla-beta:
> +               fennec-beta-latest: apk
> +            mozilla-release:
> +               fennec-latest: apk

Same comment about `default`, `maple`, and `birch` as below. If this patch works as-is, these comments aren't blockers.

::: taskcluster/ci/release-bouncer-aliases/kind.yml:66
(Diff revision 1)
> +                  firefox-beta-latest: installer
> +                  firefox-beta-stub: stub-installer
> +              mozilla-release:
> +                  firefox-latest-ssl: installer-ssl
> +                  firefox-latest: installer
> +                  firefox-stub: stub-installer

Do you need a `default` here? It might be nice to specify `birch` and `maple` as well, for easier merges + testing.
Attachment #8958917 - Flags: review?(aki) → review+
null it is. Carrying over r+
Attachment #8958915 - Attachment is obsolete: true
Attachment #8958935 - Flags: review+
Pushed by
Do not rely on release-type to define alias name r=aki
Comment on attachment 8958917 [details]
Bug 1445672 - Do not rely on release-type to define alias name

Landed on beta at:
Attachment #8958917 - Flags: checked-in+
Closed: 3 years ago
Resolution: --- → FIXED
See Also: → 1445946
You need to log in before you can comment on or make changes to this bug.