Livecode crazy version control

[newtronsols]

For example:
wait until the sound is done - worked 6.7.0
wait until the sound is done - didn't work 6.7.1
wait until the sound is done - worked 6.7.2
wait until the sound is done - didn't work 7.0.0
wait until the sound is done - didn't work 7.0.1
wait until the sound is done - worked 7.0.2

This is typical of all 'fixed' Livecode functions. One day they work and the next day/build they don't.
It must be very expensive to keep re-fixing things like this.
A huge waste of RunRev resource and regular users 'like me' - lose the plot.

[dave.kilroy]

I know the feeling - and having been bitten by 'zombie bugs' many times (they keep coming back from the grave) I keep quite a few versions of LiveCode ready to use (currently I have 8 versions in the dock) so I can choose which one to use depending on the task in hand

Actually I keep all old copies of LiveCode (even rc and dp) and have done since about version 4.5 - but that will be as nothing compared to others on the forum who have been saving them since...

[FourthWorld]

I can appreciate the frustration, but given that the language has about 4,000 tokens the number of regressions is certainly much smaller than suggested by "all 'fixed' Livecode functions".

Apple's decision to deprecate QuickTime has indeed been expensive for all developers, and with LiveCode the challenge has been compounded with the deprecation of Carbon as well. Together it requires them to not only remap existing LiveCode language tokens to new APIs, but in some cases to do so in ways where the event model in the OS is every different from how it is in LiveCode.

The engine team at RunRev maintains and regularly enhances an auto-tester tool to help catch regressions, but in all fairness consider the scope of the task: with so many tokens and so many ways they can be recombined into statements, the combinatorial explosion of possible testable states is nearly infinite. I just drop the team a note suggesting that "wait until the sound is done" be added to the test pool, and as a practical matter that's pretty much how it will go with any such a tool, that some tests can be added only when the need for the test becomes evident.

In the meantime, I was able to confirm that the specific issue involving "the sound is done" doesn't seem to be working in the latest RCs, but before I filed a bug report I figured that since there are posts like the one here where this issue is noted going back several versions it would be better for me to add my noted to the existing bug report rather than create a duplicate.

What is the bug report number for this issue?