On 2017-05-18 18:18, Mark Wieder via use-livecode wrote:
That's unfortunate. It means that, aside from distributing the widget source code, compiled widgets are bound to a specific LC version with no guarantee that they will work with any other past or future version. Does 'major version' here mean 9.x or 9.0.x? Can I assume that the binary format will stay the same across all LC9.x releases?
I'm not sure it as much of a problem as it first appears to be - because much the same is true of LiveCode Script.
If you write a script in 9 which uses features of 9, it will not work in any version less than 9.
If you write a script in 8 then yes, we work very hard to ensure that scripts will work exactly the same in 9.
So LiveCode Script is source forward-compatible (because we work had to make it so); but not source backward-compatible.
Now, much the same is true of LiveCode Builder in terms of source-compatibility (any source-compatibility issues should be reported so we can look into it). However, currently, LiveCode Builder compiles to a bytecode format which we do not guarantee inter-major version compatibility of currently (whether 'major version' here is the first version point, or first two version points is immaterial - we do guarantee binary compatibility between maintenance releases).
However, 8.1.x module format is fixed and will not change, as is lc-compile and the lcb standard library. This means that those specific builds of tools will now and forever produce modules which load into 8.1.x - so we have a LCB8.1 toolchain.
Similarly, when 9 goes GM, the module format, lcb standard library and lc-compile will forever produce modules which load into 9.0.x - so we have an LCB9.0 toolchain.
If there comes a point where we do perhaps need to break source-compatibility, we will make lc-compile more clever - making sure it can be passed a 'source version' argument. Or we will reconsider the module format slightly, raising its abstraction level slightly so this isn't an issue, write a suitable converter and happily move on.
The point is the whole problem can be sufficiently solved quite well with better tooling (which we are aware we need to work on); and in the future can be solved completely using a little bit of cleverness and exploiting the way LCB has been implemented.
I have to say I'm surprised that we're still at this state of things so far after the fanfare introduction of extensions.
It is important to remember that LCB has only been in development (on and off) for about 2 1/2 years at this point. Rust has taken over 7 to get to source-compatibiliy stage (IIRC), and Swift broke source compatibility at least twice I think since its launch - so I don't think we are doing too badly (particularly when you compare the size of Mozilla, Apple and us... I'll leave you guys to do the math there).
And on a slightly tongue-in-cheek note: I'm surprised after 26 years, the linux world has not solved its binary compatibility problem. Indeed, they don't seem to care about it one bit - even though it causes huge amounts of wasted effort for any organisation daring to consider distributing *binary only* applications. God forbid! (Also, the further you move away from glibc in the Linux stack, the worse things get in terms of source compatibility too...) ;)
Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
