| Re: Colors and Virtual Machine [message #49230 is a reply to message #49153] |
Wed, 05 July 2006 14:09   |
Karl Schultz
Messages: 341 Registered: October 1999
|
Senior Member |
|
|
On Wed, 05 Jul 2006 11:23:31 -0700, JD Smith wrote:
>> [quoted text muted]
>
>
> Hi Karl,
>
> This brings up a related but different question. How hard do you guys
> strive to keep the binary .sav format for compiled code backward
> compatible? I.e. in statements like "This compiled .sav file requires
> IDL version 6.2 or later", how far in general will "or later" extend?
> Within major version number sets (e.g. 6.x?). Or is there any
> specific policy on this?
>
> Obviously, forward compatibility is harder, e.g. allowing a
> 6.2-compiled .sav to run under v5.X, but this is typically true of
> source code as well, so there's no real expectation for that to work.
> However, 99.9% of IDL source code (my guess) is backward compatible
> --- I'm just wondering how often this compatibility gets broken for
> the compiled code, due to changes in the .sav format or other ABI
> issues?
>
> JD
Hey JD,
As you know, save files containing data are always compatible.
For code, our docs say that recompilation is needed when the "internal
code format" changes and goes on to say that the format changed back in
IDL 5.5 and any save files compiled with IDL versions prior to 5.5 need to
be recompiled to run with IDL versions 5.5 and later. I think 5.5 was
about 5-6 years ago.
Major releases tend to coincide with significant functionality improvements
and it would be too hard to time an internal code format change that is
needed right now with major feature releases. Although I do understand
the value of a major version number being associated with a stable API/ABI
level.
I think that we would advertise very clearly when such a change is made.
We did so with 5.5. This situation is a lot like changes to the external
programming interface such as the IDL_STRING string length field. I think
that we would try very hard to avoid these sorts of changes and make them
only when there are very good reasons.
Karl
|
|
|
|