Magma 1.4 on Pharo 1.4 and beyond

[Chris Muller]

Hey, that's great thanks a lot Stuart!

> A fork probably would make the most sense - though given how well you've
> split it up, I'm imagining that the bulk of the packages would be able to
> stay untouched - it'd mostly be the serialization packages which add
> extension methods to classes that no longer exist, and the few that touch
> some of the more drastic changes like FileSystem that would require forking.

Yes, FileDirectory --> FileSystem as well as SystemChangeNotifier -->
Announcements(?) are two areas that will need addressed for Pharo 2.0.

> I've actually already been maintaining my own private Metacello
> configuration for Magma 1.3 that loads it on Pharo 1.3, 1.4 and 2.0 anyway.

Great, and once you get a Pharo config going I'll join the Metacello
party for a -Squeak config; I guess Metacello is the best way to
handle multiplatform projects.

> BTW - it looks like you haven't copied Magma-Pharo-Tester from Squeaksource
> over to the Squeaksource 3 repository.

Ok, I copied it over.  I've already started the Squeak fork by
beginning to clean a couple of the methods that had case-logic
depending on whether Squeak or Pharo.  I'm not very experienced with
multi-platform development what do you think is the best way to
approach?  I'm thinking we just maintain our own forks and consume
fixes/enhancements from each other by merging them into our own fork
by hand.

I also added you as a developer to each of:

    http://ss3.gemstone.com/ss/MaBase
    http://ss3.gemstone.com/ss/Ma-Client-Server
    http://ss3.gemstone.com/ss/Magma

Hmm, I'm trying to think whether Pharo-forked versions of the same
packages should be colocated in the same repository or in a separate
one?  Let's coordinate our strategies before adding new packages.

Thanks again.

  - Chris