Changes on APL-ChangeSequence, from 1.6 to 1.12 bug fixes: - mnu #asSymbol when trying to backup changed code for methods with nil protocol - Loss of new elements in a Changes editor was possible - changes referring to discarded source code after condense changes (some change objects cannot be resolved to source code, especially method changes followed by a method remove, but also method changes referring to renamed classes) - class renames have to be propagated to change sequence elements (method changes might refer to old names of renamed classes until newly compiled) code maintenance: adapt to new handling of source/changes file references in Change objects since version 1.10 of ExternalSource (version 1.12 for VisualWorks 2.0); reduced output when filing out changes (avoid superfluous protocol headers) removed selectors: ChangeSequenceController>addDoIt ChangeSequence>updateChanges NOTE: The new code of APL-ChangeSequence propagates class renames immediately to all change sequences. The old code did not do so. If you have class renames pending in application changes, then you will have to revise them manually in order to ensure consistency. Check applications for invalid class references by inspecting the value of "ApplicationManager select: [:ap | (ap changes findFirst: [:chg | chg classObject == nil and: [chg className isEmpty not]]) > 0]" Open an Application Browser on each of the applications found and view their changes with menu item 'spawn> changes'. You may modify change objects with the help of an inspector (opened with 'edit> inspect' on the Changes Editor menu) or by evaluating "self changes renameAllClass: oldClassname to: newClassname" or "self changes renameClass: oldClassname to: newClassname" whatever may be appropriate (see method comments for details). The receiver 'self' is the application itself.