Going forward, we need to ability to have a download link for the latest 52 esr even if there has been a 60 esr (since Windows XP and others need to stay on 52 esr). Would it be possible to get: https://download.mozilla.org/?product=firefox-esr52-latest-ssl? and/or https://download.mozilla.org/?product=firefox-esr52-latest? (currently it's) https://download.mozilla.org/?product=firefox-esr-latest-ssl

This replaces the esr-latest{,-ssl} bouncer alias updates with esr52-latest{,-ssl}, instead of adding new aliases. Does that work, or do we need both?

Comment on attachment 8960244 [details] [diff] [review] esr52-latest LGTM! Do the following points make sense: 1) we need to manually create the aliases in bouncer first, so we can update them using the API 2) we land this change prior to when we build esr60 and the corresponding esr52, so the aliases don't override each other.

We definitely still need a latest esr link. The goal is that latest-esr points to latest esr (52 now, 60 when it comes out) and esr52 is always the latest 52. This is so we can provide a 52 explicit download link even during the 60/52 overlap period.

I think comment #2 is suggesting we land this patch immediately before the esr60 build. That means after the esr60 build, esr-latest* will point at esr60 going forward. If we add esr52-latest* but leave esr-latest* on the esr52 branch, during the 60/52 overlap period the non-versioned latest links will bounce between the two esrs, depending on which ran their bouncer alias updates most recently.

Hm, I suppose we may need the esr52-latest* earlier, to point people at it sooner?

> Hm, I suppose we may need the esr52-latest* earlier, to point people at it sooner? That's the plan. Basically we want to start pointing non enterprisey stuff (Windows XP, plugins, etc). to esr52 explicitly and then enterprise stuff to esr. We're planning to have a funnel where we say "esr52 this way, esr because you need enterprise this way" and they will be either 52 or 60 depending on latest.

Comment on attachment 8960295 [details] [diff] [review] land this first to update both esr-latest and esr52-latest https://hg.mozilla.org/releases/mozilla-esr52/rev/2410993fcc35

Added a human task for 60.0esr: https://github.com/mozilla-releng/releasewarrior-data/commit/7c8b03d3c9e17b6b480a264fa02aaeaeb72d2a2f

Mozharness changes the list in the config to a tuple.

Comment on attachment 8960296 [details] [diff] [review] land this before 60.0esr to stop updating esr-latest on esr52 https://hg.mozilla.org/releases/mozilla-esr52/rev/0811a5a4e9e79fda6bee253af9d6a22902808619

https://www.mozilla.org/en-US/firefox/organizations/all/ uses the firefox-esr-latest-ssl product being dropped here. Is there some contact with the bedrock team about that ? See also bug 1408868.

the plan was not to drop latest, just to add a latest 52 so we could have 52 specific links that grabbed the latest. i don't know what actually happened...

Lets reopen then, and recognise we might need to manually update the alias if we don't respin 52.8.0.

Sorry, I've not read this bug carefully enough. The checkin in comment #13 makes perfect sense for how we've previously done bouncer aliases during the esr overlap, and the additional request of having a esr52 product to persist. The wrinkle is that bug 1408868 proposes bedrock do something slightly different, which is to key off FIREFOX_ESR and FIREFOX_ESR_NEXT in https://product-details.mozilla.org/1.0/firefox_versions.json to change the product it uses in the bouncer links - firefox-esr-latest-ssl and firefox-esr-next-latest-ssl respectively.

I think we'll need all three if I'm reading things right. Once ESR60 is launched we should have firefox-esr-latest pointing at 52 still, and we'll use the old firefox-60.0.0esr-SSL product (or if it's created the firefox-esr-next-latest alias) for the new ESR60. Then once ESR60 becomes firefox-esr-latest we'll need the firefox-esr52-latest alias to allow us to easily provide a download for that line well after the normal esr overlap period. I'm assuming there will be a dedicated page on mozorg for it. It'd be best for us (mozorg team) if we could use aliases for all of this, but we are setup to get the version numbers from product-details if need be for at least ESR_NEXT.

Makes sense, except I think we're using the -ssl variants of the products, eg firefox-esr-latest-ssl. I suggest we back out https://hg.mozilla.org/releases/mozilla-esr52/rev/0811a5a4e9e79fda6bee253af9d6a22902808619 for now, so that firefox-esr-latest-ssl continues to point at ESR52. If we don't respin 52.8.0 we'll have to update the alias manually when we ship. We can reland it once we get to 60.2.0esr. I'll write some patches on bug 1408868 to make sure the firefox-esr-next-latest-ssl alias is available. Does this all make sense Aki ? Sorry barging in here.

(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #19) > Makes sense, except I think we're using the -ssl variants of the products, > eg firefox-esr-latest-ssl. You're right. We do use the -ssl variants on mozorg. There was a change to bouncer recently however that makes the non -ssl variants return the ssl URLs, making them functionally identical (can't find that bug at the moment). Should we keep using -ssl? $ curl -i "https://download.mozilla.org/?product=firefox-esr-latest-ssl" | grep Location Location: https://download-installer.cdn.mozilla.net/pub/firefox/releases/52.7.4esr/win32/en-US/Firefox%20Setup%2052.7.4esr.exe $ curl -i "https://download.mozilla.org/?product=firefox-esr-latest" | grep Location Location: https://download-installer.cdn.mozilla.net/pub/firefox/releases/52.7.4esr/win32/en-US/Firefox%20Setup%2052.7.4esr.exe

(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #19) > Makes sense, except I think we're using the -ssl variants of the products, > eg firefox-esr-latest-ssl. > > I suggest we back out > https://hg.mozilla.org/releases/mozilla-esr52/rev/ > 0811a5a4e9e79fda6bee253af9d6a22902808619 for now, so that > firefox-esr-latest-ssl continues to point at ESR52. If we don't respin > 52.8.0 we'll have to update the alias manually when we ship. We can reland > it once we get to 60.2.0esr. I'll write some patches on bug 1408868 to make > sure the firefox-esr-next-latest-ssl alias is available. > > Does this all make sense Aki ? Sorry barging in here. Makes sense, and no worries, thank you!

Backed out 0811a5a4e9e79fda6bee253af9d6a22902808619 at https://hg.mozilla.org/releases/mozilla-esr52/rev/da7a355f2f412c2681e2cf4cf10e68ff410aaf3d, and added a task on 52.8.0esr build1 to manually update the aliases when we ship. In the event we respin 52.8.0 it'll be automatic. Lets resolve this fixed, and I'll add a preflight task for 60.2.0 to backout https://hg.mozilla.org/releases/mozilla-esr60/rev/fcf3e11f9f8b39f42e791b442dbf0d9c7401915f.