The original version(s) of GLASS took a ‘kitchen-sink’ approach Seaside–everything was included, including available add-ons (such as Pier) and samples (such as the sushi store). This made it very easy to start playing with Seaside on GemStone, but makes upgrades rather awkward since it isn’t always clear which versions of which packages should be loaded together. And this is the problem that Metacello was designed to solve.

Starting with GemStone, the provided image (extent0.seaside.dbf) does not have Seaside loaded, but loading either Seaside 2.8 or Seaside 3.0 is relatively easy. The problem, is that there may be many packages you wish to unload to achieve the ‘tidy’ approach now encouraged by Metacello.

This blog post describes one such path to upgrading that I’ve used successfully.

  1. Make a backup of your system and test the following on a copy of your production system.
  2. Log in to GemStone and stop other sessions (‘System stopUserSessions’).
  3. Add to your list of Monticello repositories.
  4. Load the UpgradeTool package, giving you the UpgradeTool class.
  5. Copy the shell script in the #’shellScriptForInstallGLASS’ method.
  6. In a workspace, execute ‘UpgradeTool new doRemoveTasks’ to remove GLASS-related classes and methods.
  7. Log out of GemStone.
  8. In a bash shell, set the GEMSTONE environment variable (and PATH to include $GEMSTONE/bin), then paste the shell script code copied earlier.
  9. Review the log file to see that the script ended with an errorCount of zero (0).
  10. Log in to GemStone and turn off auto-migrate (we will do a bulk-migrate later).
  11. Re-add the GLASS repository as well as any of your application repositories.
  12. Load the UpgradeTool package as well as all of your application packages. The load should not change any code, but will add the packages to the list of loaded packages.
  13. In a workspace, execute ‘UpgradeTool new loadSeaside28’ to load the base Seaside.
  14. Load any other add-on packages (for example, SeasideAsync.g).
  15. Seaside 2.8 is now loaded, but your existing subclasses still have the old superclass. In a workspace, execute ‘UpgradeTool new doCleanupTasks’ to recompile classes and migrate instances.
  16. Check UndefinedSymbols to see that the size is only one (1)–the dictionary itself. If there are other names present, then you probably need to load additional packages and repeat the cleanup step.
  17. Initialize your Seaside applications to reregister them as visible applications.
  18. Restart the web server (Hyper or FastCGI) and try things out!

This should give you a database with your classes and data still present, but the surrounding Seaside framework should be much cleaner. Now you can start thinking about migrating to Seaside 3.0 (more on this later!).