I concluded that trying to run Fuel-1.8 in Pharo-2.0 was a pointless exercise. I needed to migrate to 1.8.x or 1.9. So I decided to migrate to 1.9 in my current Pharo-1.4 based image. This time, I've captured the migration in classes, which was not too hard (last migration I just ran code in workspaces). I tried to write a test case for the migration, but this failed strangely. When I run: ((Smalltalk at: #ConfigurationOfFuel) project version: '1.9') load: 'Core' from a workspace it works. But when it is run through a TestCase, it fails to load the newer version on top of the older version, and it fails silently - I think TestCase, Metacello, Gofer or Monticello is swallowing an exception. I tried having the test case return FLMaterializer via "Smalltalk at: #FLMaterializer" (and same for FLSerializer), but it made no difference. The test case was eventually supposed to use #forkHeadlessSqueakAndDo: to run, but I've given up on the test for now. The other oddity I noted was that FLMaterializer/FLSerializer>>currentVersion answers integers like: 18, 181, 182, 19. So, if there are ever over 100 format versions of Fuel, then there will be some confusion. This came up when I briefly considered altering the version check to allow 1.8.2 to load a 1.8 version Fuel file. On 14/03/13 10:56 AM, Martin Dias wrote:

Hi Yanni,

Could you migrate all your objects to the new format?

Best regards, Martin

On Fri, Mar 1, 2013 at 10:49 PM, Yanni Chiu <yanni-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> wrote:

...

On 01/03/13 1:54 PM, Martin Dias wrote:

...

I'm sorry but AFAIK you won't be able to materialize in 1.8.x the files you serialized with 1.8. Maybe Max has some trick to do it?

I got an exception:

FLBadVersion: Materialization error. Unexpected stream version 18 where it should be 182.

I disabled the version check, and things loaded fine. But, I've yet to find a saved file with a Date or DateAndTime instance.