On 27.02.2014, at 16:52, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

On 27 Feb 2014, at 3:45 , Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Thu, Feb 27, 2014 at 11:32 AM, Max Leske <maxleske@gmail.com> wrote:

On 27.02.2014, at 14:54, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Thu, Feb 27, 2014 at 10:48 AM, Lorenzo Baracchi <baracchi.lorenzo@gmail.com> wrote:

Hi

I was using FLMaterializer materializationFromFileNamed: filename to read fuel files.
Until yesterday everything was fine, but today I updated Pharo and received the error "'Materialization error. Unexpected stream version 19 where it should be 193."

I guess that a new version of fuel cannot (simply) read old versions files.

This is the "default" exception. But maybe....between 1.9 and 1.9.2 the file format didn't change. Max?

I think 1.9 to 1.9.3 should work without problems. I can�t think of any changes to the file format.

An interesting idea for Fuel would be that for each released version, besides defining the version, we also define the list of previous versions that are known to work with this one. So for example, we could say that 1.9.3 should work ok up to 1.9. So upon materialization we check this info. This would be very cool. Of course, it is our responsibility (humans/developers) to define with which previous versions it should work�

A versioning scheme that encodes much of the needed information directly is  great for this.

An example:

X.Y.Z-[Dialect/Version]

X - Major version changes, can not be expected to read streams of previous versions correctly (changed storage format for something)

Y - Minor version changes, can be expected to read older versions, but not newer, correctly (added new capabilities to the format, such as new hooks etc.)

Z - Internal changes/bugfixes, (no changes to the actual serialization format)

[Dialect/Version] - Not needed for error recovery if classes of serialized instances are included, as that is better to use directly if encountering missing/incompatible definitions, but a nice bit of info to start from otherwise...

+1

That�s also easy to understand for users.

Cheers,

Henry