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

[Johan Brichau]

Hi Pieter,

Not sure if it's exact the same situation, but I've done an upgrade a few months ago, where I stumbled upon some problems with the upgrade script when it comes to using github repositories etc.
I managed to get it done by creating a local monticello directory with all the necessary packages. Furthermore, it is necessary to adapt the upgrade script and add your own configuration classes.

Here is that conversation: http://forum.world.st/Glass-upgrade-seaside-image-when-requiring-MetacelloPreview-td4735961.html

Maybe it helps but I do not recognize the other issues you mention.

Johan

On 24 Feb 2014, at 15:59, pieter at nagel.co.za wrote:

> 
> Hi,
> 
> I'm struggling to upgrade a 2.4.4.4 repository to 3.1.0.4. I suspect the
> root problem is that the loaded metacello packages
> have massively diverged from the "blessed" versions that shipped with
> 2.4.4.4 in extent0.seaside.dbf, and that just breaks
> too many hard-wired assumptions in upgradeSeasideImage. For example, we're
> using recent versions of Metacello, Seaside30,
> GLASS and Zinc as published on github, we're using filetree, and that
> implies a lot of changes in lower-level dependencies
> such as Sport and SoXML etc.
> 
> To my thinking, we don't need to run upgradeSeasideImage since we've
> already upgraded Seaside; we just need to run upgradeImage
> to deal with changes in kernel classes and the GemStone product itself.
> However, when I inpect upgradeSeasideImage.topaz, it
> seems to contain code that relates to the upgrade from 2.4 -> 3.1
> itself (for example, making ControlInterrupt, Halt, Pause, Random,
> TransientRandom and BreakpointNotification obsolete).
> 
> So it seems we do need to run upgradeSeasideImage, but ensure that it
> does not trip over our different version numbers. But then
> bootstrapMaster30.topaz becomes an issue: it forcibly loads a bunch of
> hard-wired version numbers of MCZs for Metacello, Monticello and so
> on, and surely those version numbers are totally wrong for our
> dependencies?
> 
> 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.
> 
> It seems that the culprit is #BootstrapApplicationLoadSpecs - it
> seems it should list enough ConfigurationOf packages to reverse the
> effect of upgradeSeasideImage that deleted all methods in
> UserGlobals. But we're way past using ConfigurationOfGLASS now, we're
> using BaselineOfGLASS1 as published on github.
> 
> So I tried something like
> 
> UserGlobals
>  at: #BootstrapApplicationLoadSpecs
>  put: {
>    { 'BaselineOfGLASS1'. 'baseline'. #('default').
> 'filetree:///home/wonka/development/wonka/3rdparty/glass/repository/'}
> }.
> 
> but that doesn't work, since its Gofer doing the loading and Gofer
> does not seem to be able to resolve BaselineOfGLASS1 from a filetree
> repository.
> 
> Should I just hack at upgradeSeasideImage.topaz to load
> BaselineOfGLASS1? Has anyone else ever been in a similar situation?
> 
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass