Release 6.7.4 Stable / 7.0.4 Stable

Richmond richmondmathewson at gmail.com
Fri Apr 10 11:10:23 EDT 2015


On 10/04/15 15:19, Peter W A Wood wrote:
> Richmond
>
>> On 10 Apr 2015, at 19:27, Richmond <richmondmathewson at gmail.com> wrote:
>>
>> I have always thought that the idea of releasing new versions of software was to improve on earlier versions.
>>
>> And by "improving" I don't mean ignoring the fact that while you have improved your thing in one area you have
>> broken something else.
>>
>> Guess I must be wrong.
> As far as I’m concerned you are quite correct. Though I can see LiveCode’s dilemma. It was made clear during the Kickstarter campaign that the engine was in need of a lot of attention to be brought into a state where it could provide a solid base for the future. It is apparent that it wasn’t just the code that needed bringing up to date so did its source management, its automation (especially the very complicated build process) and, the most easily overlooked, its testing.
>
> I far as I can tell LiveCode is still using 20th century testing techniques (that you may know by the phrase "suck it and see”) and these do not seem to have changed until recently. LiveCode has developed a test framework for LiveCode Builder and, according to the latest blog, now has just over 500 repeatable tests and, I believe, has started to use static analysis tools to find errors in the C code. I see these as both steps in the right direction but they are small steps at the start of what will be a very long walk. (I help out in the development of the Red programming language. It’s current scope is minute compared with LiveCode, yet it has in excess of 20,000 automated tests.)
>
> Until LiveCode have built up a decent sets of automated tests which test most aspects of LiveCode, the chance of breaking things when introducing new features is going to be high. Yet LiveCode cannot stop introducing new features if it is to survive as a company.
>
> As a result, I believe you and all LiveCoders are right to be wary of each new release and not to rely on it they have tested it themselves.

This is why I suggested that RunRev put out a "Rock Solid" version that 
has been tested to the max. that people who are not really
interested in testing the latest thing and stress-busting their stacks 
can rely on; possibly for the next 2-3 years while RunRev get on
with all the other stuff.

What, however, is becoming apparent, is that almost every version since 
4.0 (see my earlier post) has got broken bits, buggy bits
or in some other way is shakey round the edges.

As version 4.0 is no longer available commercially, there is no Open 
Source version, no Free version, and I am not going to start
pirating it round the net, RunRev really does need to produce something 
that:

1. Is stable, stable, stable.

2. Has had all the stuff that has become broken fixed, fixed, fixed.

3. Will pump out standalones that work cross platform, cross platform, 
cross platform.

Perhaps, at that rate, it ought to be called "LiveCode 6.6.6" . . . LOL.

Obviously to test that version a PROPER test regime (i.e. not waiting 
for end-users to stumble on something by chance)
has to be developed.

I do think the theory that by releasing an Open Source version of 
LiveCode thousands of end-users would suddenly
put aside loads of their time for Beta testing was extremely disingenuous.

And so it has proven!

-------------------------------

Now, every time I download some Open Source stuff onto one of my 
computers it asks me questions as to whether I will
allow the program to automatically send feedback and bug-reports back to 
the mothership . . . which is a really sensible
idea and might be a good thing in LiveCode.
>
> So how do LiveCoders test their own scripts? I guess using the tried and tested techniques that LiveCode have been using.

Certainly, teachers (!!!!) who use LiveCode to pop together a 
"quick-N-dirty" standalone to deliver something, with a spot
of testing thrown in, to their charges, do not have the time to do any 
serious testing - I wonder how many other developers really have that sort
of time when there's bills to pay, mouths to feed, deadlines to meet?

I donated some money to the Open Source Kickstarter campaign (and would 
again) for the simple reason that the amount I donated was less than
a commercial licence would have cost me. I did not at that time fool 
myself that if an Open Source version did come to fruition I would spend
hours testing things. I wonder if the majority of supporters of the 
Kickstarter were not rather similar?

The only time I file a bug report and/or report it on the Us-List or the 
Forums is if I stumble upon one, not because I go bug-hunting.
>
> I admit that’s what I’ve done with the little LiveCode that I have written so far but I’ve worked out how to write an automated tests of a LiveCode Desktop application. Now I just need to find the time and, more importantly, the discipline to start to do so.

Time and discipline are what are needed, but we all have already got 
most of both our time and discipline devoted to a load of
other things.

If somebody could pay me what I make at the moment to "sit on my bum" 
for the next 5 years and give me a list of what to test with LiveCode
I might possibly do it. But the problem would be with the list, because 
with LiveCode everything has to be tested, and as the thing is holistic,
how everything interacts with everything else. I wouldn't really know 
where to begin.

I do think that RunRev should move pretty fast to get a Rock Solid 
version in place (who trusts 'stable' right now?), and regain trust.

I am sure they could do that.

Richmond.




More information about the use-livecode mailing list