Hi,
Fred Kiefer wrote:
On 24.04.2012 01:21, Sebastian Reitenbach wrote:
When a developer runs SVN, then that's fine. He usually knows, when
using a new class/method in the code,
and they can decide, whether the next release of their app will be
before or after the next core release.
But those binary changes to the Gorm files, they are not so obvious.
This obviously trapped some long time
GNUstep developers.
Does there exist a technical way that could prevent this happening in
the future? So not only make
the core libraries backward compatible, but also potentially more
future compatible?
Or is it just the developers discipline, in case he wants to release
Apps against the latest releases,
that he is supposed to use the releases while developing?
I'm just thinking, whether Gorm for example could open a Gorm binary
file, and save the representation
as a .plist file? Which then in turn could be opened by Gorm again,
to save it again as a binary again?
That would probably make porting Gorm files to older versions of
gnustep easier.
There is one more option we could think about here. We could change
the method NSArciver -encodeArrayOfObjCType:count:at: to be backward
compatible. That means this method should store all array sizes that
fit into an 32 bit integer in that space and only use the new
technique for bigger sizes. This will mean that we'll have two version
checks instead of one and of course another version increase in base.
But all these drawbacks seems minimal when compared to the current
situation where old code wont be able to load newer Gorm files.
Richard, what is your position on all this? You are definitely the
expert here and we may have overlooked a much cleaner solution.
I think Sebastian found a problem. First it is ture that both Laterna
Magica and PRICE I jsut rleased won't work on current GNUstep.
You just need top open and save gorm and it will be incompatible, even
if the same "features" re used. I don't kno how IB handles this on mac,
but except for the major format change with 10.2 (and one can still
select the older format in 10.4) as long as you don't use "new" features
NIBs are reasonably portable. So working in that direction might be
interesting.
The problem is that essentially I always track core from SVN and
encoding is given by that, even if I don't update gorm, i'm "tainted".
Riccardo
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
