This should be stored as documentation and closed...
Feedback has shown that it can be complicated for users to migrate data from one version to another. One avenue of attack is to make the data format and materialization smarter.
Here we document some best practices:
In the source image - before migrating - upgrade fuel to the version you expect to use in the new image. Here is an example script (NB if you are not on GT, you may not need to remove all the packages first):
fuelPackages := RPackage organizer packages select: [ :e | e name beginsWith: 'Fuel-' ].
fuelPackages do: #removeFromSystem
Metacello new
repository: 'github://theseion/Fuel:5.2.1';
baseline: 'Fuel';
onConflict: #useIncoming;
load.
FLVersion current
If much time has gone by (e.g. years) this might not be possible because the desired Fuel version might not be loadable in a very old Pharo image. More detail about that special case can be found in PharoEnhancement's "Fuel Migration" Lepiter page
2. If jumping from one consecutive version to the next, we should be able to handle migration automatically because SimplePersistence [now](https://github.com/seandenigris/Simple-Persistence/commit/2d4387025e9a449b15f854bb49238eddbb3ab30f) provides this. Dynabook is [already using](https://github.com/seandenigris/Dynabook/blob/10fe81c02a01f114aec95adb5f0d58f54ccbe6ea/src/Dynabook-Persistence/DynabookDB.class.st#L46) this feature. Longer jumps between distant versions might be possible too, but is untested.
This should be stored as documentation and closed...
Feedback has shown that it can be complicated for users to migrate data from one version to another. One avenue of attack is to make the data format and materialization smarter.
Here we document some best practices:
Metacello new repository: 'github://theseion/Fuel:5.2.1'; baseline: 'Fuel'; onConflict: #useIncoming; load.
FLVersion current