I've been told that they're intending to offer Atelier as a plugin to an existing Eclipse IDE as well as giving us the standalone Atelier IDE. Just wondering how close that day is.

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.

I'm not advocating making your live environment the first one you upgrade. Upgrade a QA environment initially, and do enough testing there to be confident that your app works.

I have fixed the XS whitepaper link. Thanks for reporting that. 

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.

Thanks for the feedback Ben.

I'm familiar with System Defaults, and we actively try and promote their use when we talk to Ensemble users about this issue. However, the way that Portal defaults to filing configuration item settings into the class means that it's all too easy to do this by accident. In contrast, to add/edit a System Defaults type of setting requires significantly more effort within the UI. Surely a better job could be done here?

I expect Prodlog 94592 already has the name of George James Software all over it, as we've been lobbying on this issue since the very beginning. While we wait, we've devised some techniques that allow Deltanji to leverage the OnConfigChange classmethod that a 2012.1+ production class can be given. You can read about them here.

John

Sounds good. Any estimate of when we'll get access to this?