I have been fiddling with monticello for an intense couple of days, and 
now I think it works as I always wish it should have done!

For a Monticello revolution check out this version in 
http://www.squeaksource.com/mc

Summary:

* This version for 3.9/3.10 supports pseudo-atomic loading.
* now up to date with fixes from all over the place.
* now supports out-of-order package loading.
* now supports safe package removal
    i.e. unloading a package does not break other packages.

Caveats: this has not yet been tested with traits

Benefits from the merged version: (should be)

- password manager, does not keep passwords in image.
- ignore the order of class variables
- loading FFI external structures
- copyAll versions from one repository to another
- ui fixes
-- bring the tree for dependent packages back
-- provide more progress information
-- don't scale the toolbar then resizing the monticello browser

Benefits in addition to those in previous versions:
 
    * Dont lose your method extensions!
    * Load/Unload packages to your hearts content.
    * Edit packages even when all their dependents are not present
    * Write packages designed to lie-in-wait to enhance other packages 
when loaded.

enjoy

Keith

-------------------
Details:

I have attempted to merge all of the branches of Monticello and 
PackageInfo that I could find on.

squeaksource/impara/wiresong/squeakfoundation 39a and 310.

This includes latest fixes including the PasswordManager, preamble's 
postambles, support for FFI and the ever so useful copyAll button

It seems also that the impara branch of mc supported the recovery of
overridden methods, any methods which are 'extended' by another package,
and categorized with the '-override' suffix, 'should' not be lost when 
you save a package. (I wish someone had told me about this before!)

Out-of order loading of packages, via a new class MCOrphanage.

This enables a package to 'extend', and 'override' methods in 
not-yet-loaded packages, and to subclass not-yet-loaded subclasses. Not 
yet actually loaded ('orphaned') extensions should also save with the 
package so as not to be lost.

To Do: make this loadable into 3.7 and 3.8, since I am using 3.8
for dev at the moment. See http://bugs.squeak.org/view.php?id=6476

To Do: Test with Traits.

----------
TestSpec

Loading a package uses orphanage for not yet loaded items
Description: When loading a package: Methods and classes which cant load 
go in orphanage. Before loading any package, the orphanage is added to 
the package loader in an attempt to rehome orphans.

Test 1)  out of order loading
step 1)  load package OrphanageTest-Test1
Validation: select .Orphanage and 'Browse', there should be 4 orphans in 
total comrising 2 extension methods, awaiting a class, and one class 
awaiting a superclass, and one method of this class.
step 2) load package OrphanageTest-Test2
Validation: .Orphanage should contain only 1 extension method awaiting a 
class. System categories 'OrphanageTest-Test1' and 'OrphanageTest-Test2' 
should be populated with the packages.

Test 2) As test 1, but test loading in reverse order.

Unloading package remembers to take orphans as well, and mop up
When unloading a package: Methods and classes which are in the orphanage 
for that package need to be removed as well.

When a package unloads its classes from the image it removes its own 
methods, but not its extension methods belonging to other packages, 
these need to be mopped up and placed in the orphanage so they are not 
lost.

Classes left without a superclass remain in the image, but the orphanage 
has a class definiton added, ready to relink the class with its 
superclass should it be reloaded.

When browsing or saving, the definitions of such classes should not 
include the 'AnObsolete' prefix. These classes remain in the image and 
can be modified, and remain part of the package as normal.

Testing package removal
Test 1) package removal - simple case
step 1) load package OrphanageTest-Test1
step 2) unload package OrphanageTest-Test1
Validation: .Orphanage and system category 'OrphanageTest-Test1' should 
be empty.

Test 2) package removal - complex case
step 1) load package OrphanageTest-Test1 (extends Tests 2 and 3)
step 2) load package OrphanageTest-Test2 (extends Tests 1)
step 3) unload package OrphanageTest-Test2
Validation: This should leave 2 orphaned extension methods awaiting 
their classes, one to OrphanageTest2, the other to OrphanageTest3, there 
should also be a class definition for the 'redefinition' of the now 
obsolete-but-still-present-in-the-image OrphanageTest2Subclass

The system does not return to the exact same state as after step 1, 
because the class OrphanageTest2Subclass having lost its superclass is 
now superclassed by AnObsoleteOrphanageTest2.
Validation 2: Browse the remaining OrphanageTest-Test1 to confirm that 
the class is depicted without the 'AnObsolete' prefix.
Validation 2: Select the package click 'Changes' to verify that the 
package is unchanged from the package in the repository.

Test2b) Reload OrphanageTest-Test2
Validate: OrphanageTest2Subclass now has OrphanageTest2 as a superclass.
and OrphanageTest2 now has OrphanageTest2Subclass in its subclasses.

Test2c) Unload and Reload OrphanageTest-Test2
Validate that state is similar to Test 2b)