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... Cheers, Henry
signature.asc
Description: Message signed with OpenPGP using GPGMail
