This occurs in both the Developer Edition and Nightly installers.
New: System Informer (Apr 21, 2024), Platform 29.4 (Apr 10, 2024)
1,000+ portable packages, 1.1 billion downloads
Please donate today
New: System Informer (Apr 21, 2024), Platform 29.4 (Apr 10, 2024)
1,000+ portable packages, 1.1 billion downloads
Please donate today
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
That's because they haven't been released yet. Mozilla turns off the old downloads when they turn the new ones on.
Sometimes, the impossible can become possible, if you're awesome!
Shouldn't the installer just be downloading the most recent version from Mozilla's FTP server?
Developer
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-au...
Nightly
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-ce...
Nope. It downloads the most recent package of the specific version. Firefox Developer Portable 40 was just posted. It was built this morning. It's rare for someone to want to install Firefox Developer 39 on the day Firefox Developer 40 is released.
Sometimes, the impossible can become possible, if you're awesome!
Both versions post new versions to the server at least once a day, this morning is just the newest iteration. The code merge for Dev 40 and Nightly 41 happened on Monday. Both have existed in their respective /latest folders since then.
Moreover, the Nightly standard installer at https://nightly.mozilla.org/ is version 41, but the FirefoxPortableNightly installer still fails.
When a version switch happens, they pull the old one. And we don't have a notification when the new version is posted for overlap, we rely on users to let us know. Firefox Developer Portable 40 is now released and will pull the current build from whenever you install it.
As I just explained, the current Firefox Portable Nightly is 40, which no longer exists as Mozilla pulled it from the old location. 41 will work once we release it. It's mirroring right now. It's easy to tell since our version says 40 right on it but 40 is no longer available from Mozilla. Again, this only happens when a version switch happens.
Additionally, Mozilla randomly changes the actual download URLs every few months and breaks it part way through a specific version so we have to do a revision.
Sometimes, the impossible can become possible, if you're awesome!
Why are the FirefoxPortable Dev and Nightly installers locked to a specific version? If the portable installer downloads the latest build for that version anyway, why not go one step further and download the latest build from the FTP server, regardless of the version? That way:
- there doesn't need to be a new FirefoxPortable release for every Firefox version
- there's no need to rely on users to notify you of a version switch
- existing Nightly and Dev FirefoxPortable installers won't fail during the overlap
- FirefoxPortable will be unaffected by the Mozilla randomly changing the download URLs
To my knowledge, Mozilla doesn't make a URL available that will definitively download the current nightly build sans version number. They used to, but appear to have ditched it a year or so ago. Plus, there's no guarantee that Mozilla wouldn't randomly change it as they have been the Nightly x64 links as of late.
More importantly, we want to ensure that users aren't making installs with outdated launchers. We regularly update the FirefoxPortable.exe launcher contained in all our releases, just did so last month as a matter of fact to fix a couple bugs. We don't want users mistakenly doing an install of Nightly or Developer with a year-old launcher inside that leaves things behind on every PC or breaks their profile.
Realistically, most users download via the PA.c Platform and update using the same. Manual users will be more aware of versions and likely to install when there is a new release and look for the current new version. A few hour window where it's unavailable is an acceptable downside to ensuring that users are getting an up to date version of the whole package. If we can get a notification as soon as the latest version is available, while it's still alongside the old one, we'd eliminate that window as well.
Sometimes, the impossible can become possible, if you're awesome!
I thought you could just glob for the URL:
ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-*.en-US.win32.zipThis doesn't seem like a URL prone to changing...you're saying this path gets modified occasionally?
Avoiding outdated launchers makes sense but I'm not convinced this would be a common problem. Users who've downloaded the installer and are presumably already using FirefoxPortable are more likely to simply copy their entire existing portable directory to a new location than install fresh. Besides, as I'll explain, outdated launchers are already a problem...
I don't think this is true. Manual users download FirefoxPortable once. Firefox updates on its own. As long as the launcher is still launching Firefox, the user has zero impetus to investigate if an updated launcher is available. Therefore, the launcher will almost never be manually updated by the user. I'm sure this is a large source of outdated launchers. In fact, I've been doing this for so long that my launcher is from 2011!
Both of the issues above would be better solved by having the launcher alert the user to any launcher updates on portableapps.com.
Fixing FirefoxPortable releases to Firefox versions does little to prevent users from having outdated launchers. So, I'm still not clear on why it's done this way...
Our primary focus is on users using the PA.c Platform and app store. It provides a far better upgrade experience since you know it'll upgrade properly, won't leave any spare bits behind (updating within Firefox will... nothing personal, of course), and ensures you get the current launcher (one from 2011 will cause things to break and be left behind as you move around). We're not going to have every app's launcher check for new versions. It's inefficient, redundant, and much more maintenance. The whole point of having it all centrally managed in the platform means we don't have to change it in 300+ locations, all requiring an updated app release, when we fix a bug.
How would we know what the current version is from a URL like that? Start at 99 and work backwards until we don't get a 550 Failed to change directory error?
Sometimes, the impossible can become possible, if you're awesome!
Sorry, I don't understand. Given that every portable app is available to download individually, aren't you already managing 300+ locations? Please elaborate.
In /latest-trunk/ and /latest-aurora/ there is only ever one version: the current version. Therefore, the glob will always return the current version. For example, in Windows you can do it this way:
ftp -A -i ftp.mozilla.org
cd pub/mozilla.org/firefox/nightly/latest-trunk/
mget firefox-*.en-US.win32.zip
This will get the current Nightly every time.
Thanks for taking the time to answer my questions.
We manage 300+ apps, but none of them have download/update code in their launchers. If they did, whenever we fixed that code, we'd have to update all the apps. By using the PA.c Platform, it's handled in one code location. And it lets you check for updates to 300+ apps at once without having to manually run them all (which would be horribly inefficient... and annoying).
The procedure you outline works via FTP and requires that setup. Our installer downloads via HTTP which supports no such methods. We'd need to download the page from Mozilla, scrape through the strings to get the current version, then assemble the link. FTP won't work through most corporate or university firewalls, so it's out.
To answer your previous question, Mozilla seems to change the download for the x64 nightly every couple months. We're not sure why.
Sometimes, the impossible can become possible, if you're awesome!
A live update feature is a bit much perhaps but I don't see what's burdensome about checking for updates. For example,
1) maintain a table of launchers with current version number
2) a portableapp launcher loads portableapps.com/update?app=xxx&version=xxx
3) server script queries the table and outputs 'true' if the parameter version is not the current version
So the code in the launcher simply checks if a URL returns true and then alerts the user. I think that's pretty maintainable.
I see. This is easy enough to do via HTTP as well.
You could use wget:
wget.exe -r -l1 -nd -A "firefox-*.en-US.win32.zip" http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Or just have a php script on portableapps.com serve the download to the launcher:
$path = "http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/";preg_match('/firefox-.*?.en-US.win32.zip/', file_get_contents($path), $build);
header('Content-disposition: attachment; filename='.$build[0]);
readfile($path.$build[0]);
You're still suggesting adding networking to 300+ launchers and maintaining a separate database of when updates are done to the launchers in addition to apps, which would be a maintenance nightmare.
Scraping and parsing an HTML page to pull the download would require a decent amount of new code in the PA.c Installer. And it'd need to be updated when Mozilla decides to change the name of the files again, anyway.
Honestly, there's no reason for any of this. It works just fine right now. You grab the new version and install it as new versions are released.
Sometimes, the impossible can become possible, if you're awesome!
Downloading a single file containing a '1' or '0' needs more than a couple lines of code?
Add this code incrementally as you update installers as part of your normal routine. No need to do it all at once.
I don't get it. It's a single table with two columns: App and Version.
Did you update code in a launcher? Yes? Increment the version value in the DB. Done.
Did you forget to increment the version? Do it now. Or later. No harm done.
I just provided ALL of the code. Literally. Both options scrape and parse the page and return a download.
You can check the builds on the FTP server from 2007; they use the same file name convention as they do today. I don't see them changing anytime soon.
In the unlikely case the naming convention does change, the PHP option I provided means that you can simply correct a single file on your server and all of the installers will work again.
- no need for a new FirefoxPortable release for every Firefox version
- no need to rely on users to notify you of a version switch
- existing Nightly and Dev FirefoxPortable installers won't fail during the version overlap
- far fewer outdated launchers in the wild
The existing launchers have no networking code at all within them. We first need to add the inetc plugin and then the logic to do an update. Then translate it into the multiple languages as it'll require a new popup messagebox to inform the user they are out of date. Then we'll have the increased support issues as tons of users complain (rightly) about the launchers 'phoning home' and wanting to know what sort of information is shared. Then we'll have to add logic to allow users to manually disable the update check. Then we'll have users complain that it shouldn't be doing that in conjunction with the platform, so we'll need to add logic for that as well... allowing the platform to advertise whether updates are enabled and the launcher handling that appropriately. Then we'll have people ask for that to be a selectable option as well. And don't forget the back and forth arguments about whether remote checking for new launchers should be enabled by default or not. It'll end up being disabled by default.
We'll also need to determine whether we do the check at every launch or cache it for an appropriate amount of time. Maybe 24 hours. But then people will ask to configure that as well. It will slow down every launch of the app as it will be done serially with the launch procedure, so expect complaints about that as well. And it'll slow it down a lot if the network is disconnected or if networking within Windows is misconfigured and the connection can't be made. Configuring a conservative timeout of 20 seconds (necessary for many slower networks around the world) means 20 extra seconds to launch every app configured to check for launcher updates when it can't connect due to a networking issue or misconfiguration of Windows' networking components or a proxy. (That's why it'd be disabled by default... and why the platform is configured to automatically check for updated apps/platform in the background in a separate process and silently fail if it can't connect by default).
Then we'll need to add the launcher version to the current app database. That means adding in 7-Zip support to the launcher as well since we 7-Zip our updater database. It means a 34KB download instead of a 192KB download for the raw text file. So we'll need to bundle 7-Zip's files with the launcher to handle that, adding 500KB to each package. For some apps it won't matter. For apps that are 1MB or less total, it's quite a big addition. Or we'd need to maintain 300+ individual files on our server to handle the update checks. We wouldn't want to be handling them live from the database (that's a lot of database hits), so we'd likely cache them in individual files if we go this route. We'll need to setup a cron task to handle their creation and regular updating.
Mozilla has changed the x64 naming convention twice in the last 6 months. Both times it was mid-version and broke installs.
We'd still need to do Firefox versions for every release. We package the whole app, not a live installer (we have permission from Mozilla for this). The only ones we don't do this for is Nightly and Dev since they update regularly for a version. So, only these would benefit from this process. And these are our least downloaded packages, of course (being alpha and nightly quality for testing only).
The simplest answer is, use the PortableApps.com Platform. It'll automatically tell you when an app is out of date and download and install it for you with just a click. You can even just fire it up for updates and use another menu or run it directly the rest of the time. If you prefer to do it yourself, you'll just need to wait for that few hour window to close if you happen to try to install version X of Nightly/Dev when it's just been updated to X+1 and our update is still mirroring.
Sometimes, the impossible can become possible, if you're awesome!