10.2.2 Patch Roll-up - not a SP, but a QIP or something else perhaps?

[AndrewWilson99]

OK. Given the response to Blake T in "Service Pack for 10.2.2", I believe that Esri really won't release any more Service Packs after 10,2 per Asrujit SenGupta, but there is a steady precedence over time for Esri to make things simpler for their customers and release a Quality Improvement Patches, a roll-up of patches for the penultimate version after a new version of the flagship software is released.   Really, for 10.2.2, what is it now - EIGHTEEN patches!? (Yes, I think this warrants an interrobang!)

Could we leave off the semantics of "Service Pack" and "QIP" and refine the question to:

     "Will Esri roll up the existing patches and hot fixes for ArcGIS 10.2.2 into a single installation package?"

As much as I would love to Live The Dream where we could move our applications built off of ArcGIS for Desktop and ArcGIS for Server as fast as Esri releases new dot versions, it just doesn't happen.   Having a ream of patches (plus hot fixes!) for each new install on a computer (much less the older, half-patched installs) puts the onus on users to sort through and find the right patches.   The only sure thing that results is that, due to the number of patches and onerousness of that amount, we have an even more varied configuration than one would expect.

The alternative is for organizations to home spin "patching applications" that rumble through existing patches and hotfixes using silent install scripts.   I hope that having a vendor supplied roll up would be more complete and fail-safe than the plenitude of different backyard solutions across the customer base still using 10.2.2.

(We will not be able to shift our main use to version 10.3 until after the summer field season which means there is likely to be thousands of installs and updates in this organization between now and then.)

[JoshuaBixby]

I couldn't agree more.  From the perspective of managing ArcGIS software and not just using it, things have degenerated ever since the dot releases came to light.  Beyond the sheer number of patches and lack of any roll-up, all of the back porting of patches has made for an interesting landscape.  Now we have patches that need to be applied to 10.2.1 but then re-applied after upgrading to 10.2.2, which seldom if ever happened when service packs were around because back porting was practically nonexistent between service packs.

To complicate the matter, the PatchFinder.exe hasn't had its metadata updated in more than a year.  The file properties still show the same version # as one I downloaded 12 months ago, but the one from 12 months ago doesn't see all of the newer patches.  If the file properties aren't being updated as new PatchFinder.exes are released, how are users supposed to know they have an out of date version?

[AndrewWilson99]

Given the rampant confusion and avoidance of this topic in previous conversations here and elsewhere on the "patch roll-up" topic when I saw the following link I thought a different approach might be more effective: showing an example of what software vendors do when the list of patches and fixes gets to be outstanding in an effort to have better system configuration (aids vendor's software support and users' security) as well as making it easier on the user:

• Simplifying updates for Windows 7 and 8.1 | Windows for IT Pros