[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.
From: |
Eric Wasylishen |
Subject: |
Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m |
Date: |
Wed, 7 Mar 2012 16:00:28 -0700 |
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
- Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m, Gregory Casamento, 2012/03/01
- Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m, Richard Frith-Macdonald, 2012/03/01
- Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m, Riccardo Mottola, 2012/03/01
- Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m, Riccardo Mottola, 2012/03/05
- Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m, Sebastian Reitenbach, 2012/03/06
- Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m, Fred Kiefer, 2012/03/06
- Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m, Sebastian Reitenbach, 2012/03/06
- Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m, Richard Frith-Macdonald, 2012/03/07
- Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m,
Eric Wasylishen <=
- Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m, Eric Wasylishen, 2012/03/28