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

[Eric Wasylishen]

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