v7 testing and "word"

[Richard Gaskin]

Joseba Aguayo made this very important request on the use-livecode list:

> Please, add options. Not change the options until now.
> The applications constructed now must be run OK in the new version 7.

LiveCode v7 will include some of the most sweeping changes we've seen in 
any engine build in many years.

We must all test it thoroughly.

If it's riddled with bugs it'll frustrate long-time users, hamper 
adoption among newcomers, and increase expenses for RunRev while it 
risks lowering their revenue with a bad reputation.

So we must be ABLE to test it.

If we're all spending time tracking down the inevitable cases where even 
an automated search-and-replace for "word" didn't update our code, we 
simply won't be able to spend enough time doing the sort of testing v7 
will require.

Whether this is done through synonyms to assist the transition, or some 
other means, Joseba's post reminds us that it's absolutely critical that 
v7 maintain backward compatibility to allow thorough testing.

 From the moment we run our stacks in v7, we must be able to assume that 
any issues we find with previously-working code are regression issues, 
not merely side-effects of new features.

As important as the new chunk type is, I believe it's far more important 
that the team remain keenly focused on delivering a v7 build that 
addresses unfortunately long-standing concerns of stability.

The goal of v7 is "Unicode: it just works".  Keep to that mandate, and 
find some means of handling any deviation from that goal, even if it 
means postponement of this new chunk type.

For an engine change this big, backward compatibility with long-standing 
language tokens is an absolute must, at least for now.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys