Alan Knight posted this on one of our mailing lists, and I thought it would be generally useful:

Yes, quite a lot of substantial things changed with Runtime Packager. See the release notes for some additional information. One of the significant and backward-incompatible changes, as Jim pointed out, is the change from using categories and namespaces as the organizing mechanisms to using packages and bundles. Most of the changes as to what did and did not get stripped would have made it strip less (e.g. allowing for pragmas and handling registries of classes). I don't know why it would strip productFromInteger:, and I haven't seen that behaviour.

The biggest problem with a simple, linear bootstrap chain is that the system does not start up in a simple, linear fashion. The most notable branching points in a basic image are between runtime and development usage, and between headless and headfull operation. I'm not sure where to draw the distinction is between something that allows clients to hook in their interests at a proper position and a confusing network of implicitly linked events, triggers, and pragma dependencies. In comparison to to the traditional mechanism, which could be described as a linear bootstrap chain with a place to hook interests, it proved to be too hard-coded and not flexible enough, not to have enough registration points, and the registration mechanism led to ordering dependencies on exactly when particular interests were registered. The Subsystem mechanism, and the SystemEventInterests have allowed for considerably greater flexibility, and there are a number of things implemented as a result that would have been quite difficult to do as ObjectMemory dependents.

I'm not sure if you were wishing for a tool that would show the ordering dependencies or complaining that one is necessary, but there is one. See Tools-StartupOrderingTool, which adds a tab in the RB code view when a Subsystem class is selected.

To disable the command-line options that we thought you might want to disable for security reasons, See Settings->System->Loading, or the class side of ImageConfigurationSystem.

Dynamically pausing parts of the system during runtime is something that has been part of the system since the beginning, and is fairly widely used. The mechanism on Subsystem merely makes it possible to do this for Subsystems without making them be dependents of ObjectMemory.

I suspect the increase in footprint from 7.3 to 7.4 is more likely due to the more conservative approach to stripping when confronted with difficulty to correctly trace constructs such as pragmas and class registries than to links between subsystems, but it's possible that that is a factor. I also note that by default the system will start by including all Subsystems in the image, and they would have to be explicitly excluded. You might be interested in looking at base.im as a basis for stripping, rather than a full development image, or at unloading development-time only functionality before stripping.

Improving and automating deployment procedures is one of our priorities, and the changes in Subsystems is part of that, as are the changes to Runtime Packager. We think the basic Subsystems code is stable, although adapting other parts of the system to use those mechanisms such as was done for Runtime Packager in 7.4 is still ongoing. Runtime Packager is likely to have more changes, and also to have less emphasis as the primary deployment mechanism, particularly with respect to stripping a development image.