So I appear to not be the only one seeing this… JSS says "yo dawg Firefox 58.0 is available go treat yo self" but AutoPkg doesn't pick it up, the apps don't pick it up as an in-app update, and the download link served up on https://download.mozilla.org/?product=firefox-latest-ssl&os=osx&lang=en-US is still pulling 57.0.4. So, did a Jamf jump the gun on this one? Which begs a further question: how is Jamf validating the patch titles for new versions?
The automation we have configured pulls Mozilla Firefox versions from their FTP site: https://ftp.mozilla.org/pub/firefox/releases/
Mozilla Firefox 58.0 has been available since January 19th: https://ftp.mozilla.org/pub/firefox/releases/58.0/
If the community would rather we use another source, or Mozilla's release calendar feel free to let us know.
The Release Process is outlined here: Jamf Process for Updating Patch Management Software Titles
Automation is only used to as an indicator, step 1. Steps 2 through 6 are performed by the Patch Curator and the Patch Reviewer.
Here is the JNUC 2016 video that also goes through the release process: JNUC 2016 Patch
It seems that at least in this case Mozilla is the one causing most of this distress. For instance, although 58.0 has been up on https://ftp.mozilla.org/pub/firefox/releases/ for a while, /latest/README.txt would have us use something like https://download.mozilla.org/?product=firefox-latest&os=osx&lang=en-US (which as of today still points to 57.0.4, and which would cause the same problem for any autopkg recipe looking at /latest). Maybe worth mentioning to [firstname.lastname@example.org](mailto://email@example.com)?
If the release is available technically people could download and install it on your fleet so you kind of do want to be able to detect it.
But in general it's not really useful to most people until the internal updating process for Firefox detects it and/or the main downlaod page serves it up.
It's a bit of conundrum caused by the way Firefox is releasing thinks me thinks.
Curious why would anyone want to deploy the consumer version of Firefox, when Firefox ESR is there for enterprise.
I guess the versioning confuses people. You know, the bit regarding Firefox (mainline) 57.0.4 being equal to Firefox ESR 52.5.4.
Oh well, not my farm. Not my pig. ¯_(ツ)_/¯
The timing of feature updates for ESR is not ideal at all for Southern Hemisphere educational organisations.
The early year update is generally shortly after southern hemisphere semesters / school years start, that means you are either doing a major feature update immediately after redeploying classrooms or you are using the somewhat out of date previous mid year update.
The timing of the mid year update is equally not in sync with the Southern Hemisphere educational timetables.
For education at least it often works better to be making lots of smaller feature changes across the year instead and keeping classroom machines as close as possible to what Students have on their devices (some of which are using BYOD devices alongside classroom machines).
If ESR was January/December and June/July it would be a different story, but that probably wouldn't suite other parts of the world.
I saw the same thing yesterday where the "CurrentRelease" Url kept pushing 57.0.4. My guess is it was released and then pulled for some reason. But the 58 version didn't show as current until today. I'm not quite sure why this would have hit the JSS patch reporting as current if the links didn't actually work yet though, considering its been 3 days since Microsoft Auto Update Version 3.15 was released and we still don't see that reflected in patch reporting.
Princeton Public Schools