[Glass] Upgrade GS 2.4 -> GS 3.1 when GLASS, Seaside etc. versions have already diverged

[Pieter Nagel]

On Mon, 2014-02-24 at 09:18 -0800, Dale Henrichs wrote:

> In 2.x a number of the exception classes were part of GLASS and were
> subclassed off of the class ExceptionA. In 3.x some of the exception
> classes are part of the base and the ExceptionA class no longer exists
> (it is an obsolete class) ... the upgradeSeasideImage script does the
> dirty work to make this type of transition as simple as possible.

Ok, I thought those were obsolete kernel classes; but handling them in
upgradeSeasideImage makes sense after your explanation.

>         The most common problem I have is that the image just ends up
>         with
>         crucial methods and classmethods totally gone on classes that
>         are
>         subscribed to SystemLoginNotification, causing login errors
>         that trips
>         up topaz, stopstone, gemtools.
> 
> 
> Is this after you have done a upgradeSeasideImage? There is a global
> that can set before starting the upgrade
> (BootstrapApplicationPostloadClassList) where you  define the list of
> classes that you want to have initialized after the upgrade ...
> unconditional sending of #initialize during the upgrade process could
> wipe out critical data structures so this "opt-in" process was adopted
> so that you know exactly which initialize messages are being sent ...
> for the SystemLoginNotifications it sounds like those classes involved
> need to be added to the list.

It was not a matter of something needing to be added to the list;
something already added to the list was broken. What happened is that
OTRemoteDebugger had lost all its methods (including #sessionStart),
which caused a DNU when SystemLoginNotification tried to call it at
login time, which caused topaz to increment its errorcount, and made all
topaz scripts fail with exit code 1 thereafter, and all kinds of other
fun in gemtools and stopstone. 

I now understand this is due to upgradeSeasideImage looping over all
classes in UserGlobals and doing removeAllMethods class side and
instance side. Without a working #BootstrapApplicationLoadSpecs, the
majority of the removed methods never got re-added at all.

So tomorrow I'll focus on getting a BootstrapApplicationLoadSpecs that
somehow pulls in BaselineOfGLASS1 and see how that goes.

> I don't think you should hack the upgradeSeasideImageScript.

The alternative seems to be generating an equivalent MCZs repository for
all the filetree stuff, and then I'd have to automate the creation of
that repository into our build process so it stays in sync with the
github filetrees - I dislike manually created copies of data that can
get out of sync.

I'll experiment with an empty #BootstrapApplicationLoadSpecs, but
instead somehow create a class whose initialize just calls our existing
source code bootstrapping scripts (that load the new Metacello,
filetree, BaselineOfGLASS, and our code). I can arrange for that to be
triggered via #BootstrapApplicationLoadSpecs. That should circumvent the
need to edit upgradeSeasideImage and give me a hook to load our code
with a newer Metacello.

>