Ok. So Iceberg will not try to wrap other modes of conversion and versioning like STON STON is not for versioning code. But objects. Yes, I know. I was referring to its possible use in moving Smalltalk between environs. Itâs normally used for domain objects, but it could be used to serialize code itself (just another domain object), if we have no universal chunk format for Smalltalk. Seems that STON could be managed somehow from within Iceberg to move class/method definitions, but we also have the different package- and namespace- structures needing specialization for each environment. Similar comments apply to unique syntax specializations, like the period-delimited literal-array evaluables possible in Pharo, but not in VW, for example. STON under Iceberg might also let us add or strip class-name prefixes, automatically, when porting between Smalltalks with/without modules/namespaces, like VW and Pharo, for example. Iâm thinking every Smalltalk would have an Iceberg. It would be the go-to tool for versioning and conversion of Smalltalk code for any environ. For now, Iâll settle for getting Iceberg to work reliably in 7.0.3. Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Which Iceberg material is most up-to-date for Pharo 7.0.3? Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? My Pharo 3.0.7 install and all repos are in non-default directories, and Iâm wondering whether this is causing the crashes. and Monticello to provide a kind of seamless LCD approach and some backward compatibility with Monticello (without encouraging new use of Monticello)? No because the distance is too large. We cannot burn our two engineers on ânice to haveâ when the âmust haveâ is not yet done. Now migrating to iceberg is super easy and configurations are a lot simpler than with monticello. Stef Shaping