That's certainly a useful tip. I wonder if it would have helped in a situation we assisted an Ensemble site with last year. They'd upgraded their DEV and QA environments from 2013.1 to 2015.1 but their LIVE was still on 2013.1. Then they amended an HL7 schema in DEV, exported it, imported it to QA, verified it worked, and finally loaded it to LIVE, where it broke the production.

The cause turned out to be a change made in 2014.1 and documented in a bullet point here. Yes, they had been unwise not to retain a QA or pre-live staging environment on the exact Ensemble version that LIVE was running.

I take your point about keeping up with the technology curve, but it's no good the next release of your app using all the whizzy new features of the latest Caché version if you're not able to deploy it to your customers until they can be coaxed to upgrade. Yes, you can use the new features as a carrot to entice them to upgrade, but meanwhile you probably have support commitments to them that mean occasionally patching the app release they're currently using.

At analysis time you can choose which packages to include. The webapp whose time-based graphical output I showed above doesn't let you filter a whole-namespace analysis to view only the stats for a single package. But the Structure101g Studio tool gives a lot more power. For example, here's a drilldown into the top-level packages:

Overall bar length is code size. The red portion is the XS of the package.