https://code.google.com/p/fuel/issues/detail?id=207 On 27.02.2014, at 17:06, Max Leske <maxleske@gmail.com> wrote:
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