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

[Dale Henrichs]

On Mon, Feb 24, 2014 at 10:17 AM, Pieter Nagel <pieter at nagel.co.za> wrote:

> 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.
>

Yes, that is standard for the upgradeSeasideImage script ... there are a
number of moving parts underneath the covers in GLASS so the safest upgrade
strategy is to remove all methods and add them back again ...

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

The entries in BootstrapApplicationLoadSpecs should track your bootstrap
installation script and to get things bootstrapped correctly I think you
should include a a line in the BootstrapApplicationLoadSpecs for
bootstrapping the initial starting point for ConfigurationOfGLASS for 3.1
which is the following:

  {'ConfigurationOfGLASS'. '1.0-beta.9'. #('default').
BootstrapRepositoryDirectory. }.

That should be followed by a

{'ConfigurationOfGLASS'. '1.0-beta.9.1'. #('default').
BootstrapRepositoryDirectory. }.

which gets you to the point where GLASS1 might be loaded ... Note that the
seasideUpgradeScript expects that all of theconfiguartions  be present
BootstrapRepositoryDirectory. Also note that the upgradeSeasideImageScript
expects to be loading Configurations for all artifacts ...


>
> > 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.
>
>
As I said earlier I think that you should get a minimun of GLASS
1.0-beta.9.1 loaded via the upgradeSeasideImage script, because that will
mean that the basic functionality of GLASS will be present and initialized
...

The upgrade script was created before I started introducing the github
based repositories so it is wired to be loading configurations instead of
baselines, but if you get GLASS1.0-beta.9.1 installed, you should be able
to do post-upgradeSeasideImage loads with you standard bootstrap scripts ...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140224/dd95c668/attachment.html>