On 27.02.2014, at 16:52, Henrik Johansen <[email protected]> wrote:
> > On 27 Feb 2014, at 3:45 , Mariano Martinez Peck <[email protected]> wrote: > >> >> >> >> On Thu, Feb 27, 2014 at 11:32 AM, Max Leske <[email protected]> wrote: >> >> On 27.02.2014, at 14:54, Mariano Martinez Peck <[email protected]> wrote: >> >>> >>> >>> >>> On Thu, Feb 27, 2014 at 10:48 AM, Lorenzo Baracchi >>> <[email protected]> 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
