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.