https://code.google.com/p/fuel/issues/detail?id=207


On 27.02.2014, at 17:06, Max Leske <[email protected]> wrote:

> 
> 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

Reply via email to