These should point to the latest firefox releases for our primary operating systems.

Here's the plan: Create a "Firefox-latest" product. For each platform, create a location for "Firefox-latest" that points to the same paths as the Firefox-15.0 product.

http://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US http://download.mozilla.org/?product=firefox-latest&os=osx&lang=en-US http://download.mozilla.org/?product=firefox-latest&os=linux&lang=en-US http://download.mozilla.org/?product=firefox-latest&os=linux64&lang=en-US

Apologies if this has been addressed elsewhere, but what will we need for testing prior to releasing a new version ? ie will we need another product prior to shipping, and some sort of switch to pass the stub installer to make it use that ?

I'm not entirely sure I understand the question but I'll give it a go. The stub will always get the latest release, latest beta (needs to be implemented in bouncer), latest aurora (still needs to be implemented on the server side), and latest nightly (still needs to be implemented on the server side) so it will just get the yet to be released version. I'll think on adding a command line switch to add capabilities like this but I have bigger things to work on, there are potential security concerns which would require another security review, and I have little time to do work on out of scope things atm.

I think we can set up all four channels in the short term, even we make things more robust after the initial setup, so I'm not worryied about blocking you there. The issue I'm raising is that we'll have a set of version-specific locations in bouncer for product like Firefox-latest, and RelEng will need to update them to point at the next release. I'd like to have a way to minimize the amount of untested hot-swapping involved in that. One possibility is * Firefox-latest points to current (eg 15.0.1) * Firefox-latest-test points to upcoming release (eg 16.0) * QA tests the stub installer by launching it with an extra argument (eg -test), that appends -test to bouncer product name * at release time RelEng renames Firefox-latest to Firefox-latest-old, and Firefox-latest-test to Firefox-latest Does the stub installer support resuming downloads ? If it does and a user starts a download prior to that swap then continues afterwards, they could get installer which is a mixture and broken in all sorts of interesting ways.

Per a conversation with catlee I removed the non-windows locations for the firefox-latest product, leaving just win since that's all that is needed right now for the stub installer.