Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m

[Eric Wasylishen]

Hi, any other thoughts on this? I still think my proposed solution is the best 
option: changing systemVersion to a fixed integer, and only incrementing it 
when we make changes that break compatibility.

i.e. change NSCoder.m:

- (unsigned) systemVersion
{
  return (((GNUSTEP_BASE_MAJOR_VERSION * 100)
    + GNUSTEP_BASE_MINOR_VERSION) * 100) + GNUSTEP_BASE_SUBMINOR_VERSION;
}

to:

- (unsigned) systemVersion
{
        // Please increment when you make a change to the archive format
        // that any older versions of the library won't be able to read, and
        return 40000;
}

We could also make a change in NSUnarchiver to check if the version of the 
archive being read is greater than NSCoder's systemVersion, in which case we 
won't be able to read the archive and can throw an exception (?).

-Eric


On 2012-03-07, at 4:00 PM, Eric Wasylishen wrote:

> Hm… to me it would make more sense if systemVersion was an arbitrary number 
> that we increment only when we make a change to the archive format.
> 
> If I understand it correctly, with the current scheme, an old version of 
> gnustep-base can't tell if it is able to read an archive or not (it doesn't 
> know that at 1.24.2 there was a change to the archive format). If we use 
> arbitrary numbers, incremented when a format change is made, an old version 
> of gnustep-base can tell for sure whether it can safely read an archive saved 
> by a newer version of gnustep-base.
> 
> Eric
> 
> On 2012-03-07, at 1:16 AM, Richard Frith-Macdonald wrote:
> 
>> 
>> On 6 Mar 2012, at 09:32, Fred Kiefer wrote:
>> 
>>>> 
>>>> There don't seem to be anyone using Gorm on OpenBSD from the packages.
>>>> I'd guess, otherwise, the problem would have shown up much earlier.
>>>> Therefore I'm not sure, whether there is a real need to fix that in
>>>> -base. But I definitely
>>>> should fix it in the Ports/Packages.
>>> 
>>> I think you are wrong here. The mismatch of the archive numbers could not 
>>> have caused any problem before the change to NSArchiver. This means, we 
>>> don't know if any gorm files or other archives made on OpenBSD are 
>>> affected. We have to plan for the worst and try to come up with a solution 
>>> that allows for these archives to be read in correctly.
>>> 
>>> I would like to propose an over cautious solution: We decouple the archiver 
>>> systemVersion from the library version and make it bigger than any number 
>>> already used on OpenBSD, lets say, library version + 4 (= 5.24.2). And make 
>>> this the version that gets special treatment in NSArchiver, plus of course 
>>> 1.24.2 (hopefully this specific number hasn't been used on OpenBSD), as we 
>>> already have new archives produced with that number. And on OpenBSD, we 
>>> need to guaranty that such mixing of version numbering never happens again.
>>> We also need to investigate the whole base code, whether there is another 
>>> place where we might have such a mix.
>> 
>> I've been thinking about this ... I really don't like the idea of separating 
>> the value returned by -systemVersion from the version of the system ... it 
>> just seems wrong.
>> 
>> This is simply a bug in the OpenBSD  package, nothing to do with GNUstep 
>> directly ... but we ought to do a workaround.
>> 
>> What I'd suggest is a temporary hack (meaning we should remove it in a few 
>> years) to recognise version 4.0.0 as actually meaning 1.24.1 unless the 
>> current system version is 4.0.0 or later, so that decoding old archives 
>> works (though we should probably report the incident using NSLog()).
>> 
>> Given that our version numbering increases really slowly,  I wouldn't expect 
>> us to actually get to version 4.0.0 for several years, by which time old 
>> OpenBSD specific archives should not be an issue.
>> _______________________________________________
>> Gnustep-dev mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>