From https://bugzilla.mozilla.org/show_bug.cgi?id=1387622#c27: The way it's handled on the site is that both versions are listed on the download page when FIREFOX_ESR_NEXT is defined in product-details[0]. You're right that there is a planned 6 week overlap after a new ESR release and they're both available at: https://www.mozilla.org/en-US/firefox/organizations/all/ Which is the only page from which ESR is downloadable. So either way will work for me I think. What I believe will be easiest is for the firefox-esr-latest-ssl alias to stay on the old version during the transitional period, and we can use the value of ESR_NEXT in product-details to produce those download buttons. A really-really easy thing would be for there to exist a firefox-esr-next-latest-ssl alias when a new ESR is released so that we can use aliases for both, but that is really just me wishing out loud (no idea how difficult these things are to do). Hope that's clear and helpful. [0] https://product-details.mozilla.org/1.0/firefox_versions.json ----- That should be no problem to implement. RelEng just need to make sure we have bugs and docs set up so we don't forget in the meantime.

This is great! Thanks. So in your opinion I'm safe to update the buttons on the site to use firefox-esr-latest-ssl now and then the ESR_NEXT version value from product-details when that becomes a non-empty string? Sound right? If the firefox-esr-next-latest-ssl alias becomes a thing that's a bonus, but for now I'm going to assume I need to use the version in the bouncer link for the ESR Next buttons.

Bulk change of QA Contact to :jlund, per https://bugzilla.mozilla.org/show_bug.cgi?id=1428483

pmac, does bug 1445666 solve the problem to you satisfaction ?

It's obviously different to what is mentioned above, but might still be OK ?

I think that's a different thing, but I also am not sure what the future of ESR is TBH. Do we still expect there to be the overlap release period for the foreseeable future? My understanding is that bug 1445666 is about providing a download URL for ESR 52 even beyond the normal phaseout period for a normal ESR because 52 will live longer as a legacy platform for legacy addon support. So this might work for this overlap period, but we should also solve for what will happen during the ESR 60 and 68 overlap. The basic point for now though is that I need to know what to expect from product-details when ESR 60 is released so that I can make sure that the site will behave appropriately. And bug 1445666 will help by also providing a bouncer product we can use for support for 52 downloads after ESR_NEXT goes away.

Nick - if I'm understanding this correctly with the 60 ESR release the 52 release will still be offered for another 6 weeks. Both the 52 offering and the 60 offering will be provided to users (the toggle between the pages containing either build appears) in the /organizations/all page via "FIREFOX_ESR" and "FIREFOX_ESR_NEXT" and, most importantly, releng takes care of that already (no request to do so is required). please confirm (or correct me)

The overlap between 60 and 52 is actually 12+ weeks. 52 EOL is late August/early September I believe And that will continue for other ESR releases. We always allow a 12 week overlap to allow for qualification So the goal would be to have links for "latest52" (which we have) and latest-esr.

I think we'll need to update https://github.com/mozilla-releng/ship-it/blob/b9785e897f9d7f9f79ae85cf4df015ac3d93b6bc/kickoff/config.py#L8 so that product-details knows how to set FIREFOX_ESR_NEXT (specifically how to scan for the right versions in ship-it). cc jlorenzo since he's driving the setup of ESR60 and knows ship-it well. pmac: do you still want to implement comment #0 ? Do we still have time to do so before 60.0 ships in a week ?

(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #8) > pmac: do you still want to implement comment #0 ? Do we still have time to > do so before 60.0 ships in a week ? We are already using the "firefox-esr-latest-ssl" alias in our bouncer links for ESR on the site now. If releng were to create the "firefox-esr-next-latest-ssl" alias as well I could use that when the new ESR is released. Failing that I can continue to use the version value from the ESR_NEXT key in product details. I'll double check, but the site should be setup to do the latter now once the ESR_NEXT key has a value, but I could easily make the change to use the alias if you think there's time to get it working.

(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #8) > I think we'll need to update > https://github.com/mozilla-releng/ship-it/blob/ > b9785e897f9d7f9f79ae85cf4df015ac3d93b6bc/kickoff/config.py#L8 so that > product-details knows how to set FIREFOX_ESR_NEXT (specifically how to scan > for the right versions in ship-it). cc jlorenzo since he's driving the setup > of ESR60 and knows ship-it well. This is already filed as bug 1452948.

erenaud, short answer is we're working on it, and should be ready in time. No further requests needed.

Comment on attachment 8972493 [details] [diff] [review] [esr60 only] Use firefox-esr-next-latest & firefox-esr-next-latest-ssl until 60.2.0 If we do this plus https://hg.mozilla.org/releases/mozilla-esr52/rev/0811a5a4e9e79fda6bee253af9d6a22902808619 , nothing will update the firefox-esr-latest{,-ssl} aliases. If this is the route we go, we should probably back the latter patch out of esr52.

Comment on attachment 8972493 [details] [diff] [review] [esr60 only] Use firefox-esr-next-latest & firefox-esr-next-latest-ssl until 60.2.0 https://hg.mozilla.org/releases/mozilla-esr60/rev/fcf3e11f9f8b39f42e791b442dbf0d9c7401915f

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. There's a prereq on 60.2.0esr in releasewarrior to back out fcf3e11 from esr60. Docs to follow.

Comment on attachment 8972923 [details] Bug 1408868 - Set bouncer alias in taskgraph and removed duplicated configs https://reviewboard.mozilla.org/r/241484/#review247306 Whenever I see configs cleaned up from mozharness and moved within the tascksluter kinds, it's music to my ears. LGTM!

Comment on attachment 8972493 [details] [diff] [review] [esr60 only] Use firefox-esr-next-latest & firefox-esr-next-latest-ssl until 60.2.0 I'm sorry. Since bug 1433459, these configs files are unused. I made a patch that changes the task definition.

Comment on attachment 8972923 [details] Bug 1408868 - Set bouncer alias in taskgraph and removed duplicated configs Landed on esr60 at: https://hg.mozilla.org/releases/mozilla-esr60/rev/e1c89bf28365823de83262354b17801158d9414f

Comment on attachment 8972930 [details] [bouncerscript] Support firefox-esr-next-latest* aliases LGTM! Left a tiny non-blocking comment in the PR to address later on.

Pushed by jlorenzo@mozilla.com: https://hg.mozilla.org/build/puppet/rev/ca89e5c8b665 Bump bouncerscript to 1.3.0 a=versionbump

Comment on attachment 8972937 [details] Bug 1408868 - Bump bouncerscript to 1.3.0 a=versionbump Landed on * default https://hg.mozilla.org/build/puppet/rev/ca89e5c8b6659934e13a01be56f302f05f3afdfd * production https://hg.mozilla.org/build/puppet/rev/8457305c8cddd4e242271a0a41ac754a04e3f3ba

We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again. hg error in cmd: hg rebase -s d6f0654e8e9dcbe6af4234c61be6ec130c25e04f -d 718d6eca69f2: rebasing 462056:d6f0654e8e9d "Bug 1408868 - Set bouncer alias in taskgraph and removed duplicated configs r=mtabara" (tip) local [dest] changed testing/mozharness/configs/releases/bouncer_firefox_esr.py which other [source] deleted use (c)hanged version, (d)elete, or leave (u)nresolved? u local [dest] changed testing/mozharness/configs/releases/dev_bouncer_firefox_beta.py which other [source] deleted use (c)hanged version, (d)elete, or leave (u)nresolved? u local [dest] changed testing/mozharness/configs/releases/dev_bouncer_firefox_devedition.py which other [source] deleted use (c)hanged version, (d)elete, or leave (u)nresolved? u unresolved conflicts (see hg resolve, then hg rebase --continue)

jlorenzo, thanks very much for fixing this up. Could you please update the prereq in https://github.com/mozilla-releng/releasewarrior-data/blob/master/upcoming/firefox/firefox-esr-60.2.0esr.md for your changes.

(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #26) > jlorenzo, thanks very much for fixing this up. Could you please update the > prereq in > https://github.com/mozilla-releng/releasewarrior-data/blob/master/upcoming/ > firefox/firefox-esr-60.2.0esr.md for your changes. Good point. Done in https://github.com/mozilla-releng/releasewarrior-data/commit/638c16de219715e3a0725e9e0b56fe646a0cc250

Pushed by jlorenzo@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/cbdef048e40c Set bouncer alias in taskgraph and removed duplicated configs r=mtabara

[task 2018-05-07T23:53:58.048Z] IOError: Can't find releases/bouncer_firefox_beta.py in ['.', '/builds/worker/checkouts/gecko/testing/mozharness/configs']! Guessing https://hg.mozilla.org/releases/mozilla-beta/rev/cbdef048e40c nuked too many config files.

The config files are used by bouncer check. I imagine we need all of them.

Pushed by asasaki@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/6b2dbc03a102 back out the broken portions of cbdef048e40c. r=backout a=release

https://hg.mozilla.org/releases/mozilla-esr60/rev/f7e822f67a4490520630cc8271b948c0fa30d112 https://hg.mozilla.org/releases/mozilla-beta/rev/4e53a8d0713173885c9debef317f14dff76bb877 https://hg.mozilla.org/integration/mozilla-inbound/rev/6b2dbc03a10225abf4dd400d865142029564b360

Both current ESR builds are displaying properly on https://www.mozilla.org/en-US/firefox/organizations/all/ \o/ I also notice that the new "firefox-esr-next-latest-ssl" alias is working: $ curl -I "https://download.mozilla.org/?product=firefox-esr-next-latest-ssl&os=win64&lang=ach" HTTP/1.1 302 Found Location: https://download-installer.cdn.mozilla.net/pub/firefox/releases/60.0esr/win64/ach/Firefox%20Setup%2060.0esr.exe Does this mean that this new alias will permanently work (be automatically updated) and that I can now change www.m.o to use that instead of links directly to v60esr?

My plan is for the two firefox-esr-next aliases to be updated for 60.0.x and 60.1.x, but only firefox-esr pair from 60.2 until the next ESR.

(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #36) > My plan is for the two firefox-esr-next aliases to be updated for 60.0.x and > 60.1.x, but only firefox-esr pair from 60.2 until the next ESR. I would only be using the firefox-esr-next-latest aliases during the time when product-details has a value in FIREFOX_ESR_NEXT. When that goes blank again the site will show only a single ESR download on the /firefox/organizations/all/ page and those links will use the firefox-esr-latest aliases. I believe that coincides with your plan. Correct?

Yes, I think so. We'll just have to update https://github.com/mozilla-releng/ship-it/blob/master/kickoff/config.py#L7 to achieve FIREFOX_ESR --> '60.2.0esr' and FIREFOX_ESR_NEXT --> ''. I've filed bug 1460752 for that, and added it to our release task tracker.

Great! I'll file an issue to go ahead and get our buttons updated to use the alias. Thanks all!

Pushed by mozilla@hocat.ca: https://hg.mozilla.org/integration/mozilla-inbound/rev/c75b6906dab6 use firefox-esr-next-latest{,-ssl} bouncer aliases until 60.2.0, r=aki