Um . . . spotting bugs.
Well, I should like, first of all, to categorise bugs in LiveCode into
(at least) 2 types:
1. Those that have been present in LiveCode for yonks and seem to have
been overlooked, brushed-aside
or forgotten.
2. Recently occurring bugs that:
2.1. Will end up in category #1 or
2.2. Be addressed quite rapidly.
We can see from the problem with the Properties Palette not expanding
that IF enough
people "shout" loudly enough this sort of thing is sorted out quite quickly.
"Yes, using the latest LC version is, shall we say, half the battle!"
Yes, but it is the easier half . . . as bugs suddenly get noticed in a
version that have been lurking "there"
for a long time.
So, if one is a dedicated bug-hunter one has to, then, work one's way
back through (potentially)
an awful lot of versions of LC to pin down when that bug started
manifesting itself.
-----
So, "for the sake of sausages":
1. I find a bug in LC 9.0.4
2. I have to trawl back through the RC versions of 9.0.4 (this is a
technique termed "RC Cola"),
9.0.3, 9.0.2, 9.0.1, 9.0.0 and so on, possibly for a long, long time.
3. And, pray tell, is there any point knowing that bug No. 987654321 in
LC 9.0.4 has been
sitting "there" since LC 7.1.4? Probably not. The thing needs fixing,
and that's all.
------
This is all very fine and dandy if one is one of the idle rich who is
not worried about the time
involved in this sort of exercise because the fridge is permanently
stuffed with edibles regardless
of whether one does any "fruitive" work or not.
------
"install the latest build AND an older version"
That begs a question: which older version?
I have a Linux box that has every version of LiveCode from version 6.0.1
through to about 9.0.0.
It is currently under the bed with the cat; but, unlike the cat, the
hard drive is due for a reformat
and a new operating system because it is so choked with things (LiveCode
installs being only
the part of the problem) it can hardly get out from under the bed in the
morning.
------
"current work varies, projects change and some get put on the back
burner for a while, so people aren't running every line of their code
again immediately on each DP version."
Ouch: I'd forgotten about Developer Previews.
Personally (but, hey, I'm a selfish type), I tend to stick with the
stable versions because I do not enjoy
the sort of situation where, having been working on a stack for a week,
the whole thing goes West,
hosing all that time and effort.
Of course, if a bug crops up I'll note it down: but, generally, I'm
b*gg*red if I'm then going to run my latest stack
through 57 recensions of LiveCode to find when that bug manifested itself.
-------
"regressions"
There's a misnomer if ever there was: it seems to imply that something
in LiveCode
has triggered a return to a previous situation in an earlier version.
While that is possible I would not characterise that as a bug, I'd
characterise that as someone
somewhere having done some inadequate housekeeping.
------
"if everyone always moved to the latest
version (bonus for testing with RC and DP versions) then
regressions would probably be spotted fairly quickly"
I can think of many powerful reasons why people wouldn't do that.
At least one respondent round these parts, among others is always writing
(mainly on the Forums) about how unwise it is to use beta and
pre-release versions of software!
Certainly, when I was running macOS 10.14.5 beta something and my
mouseClicks started
behaving oddly I regretted signing up to the macOS beta programme.
-------
Right: I'm back off to my "Grendel" software which has a deadline for a
conference on Anglo-Saxon
next Sunday.
No beta versions in use for that!
Richmond.
On 19.05.19 2:42, Curry Kenworthy via use-livecode wrote:
Brian:
> Looking at the beginning of the thread, I think what Richard
> meant initially is that
Yes, using the latest LC version is, shall we say, half the battle! :)
But another big part of the solution is keeping an older LC version in
the loop and on the radar for comparison.
Is it ideal to promote only part of the real solution when we can just
as easily promote a more complete approach? Regressions involve
change. Noticing change often requires comparison. Not always -
sometimes a bug is really obvious, or it noticeably affects the user's
current work.
But often that's not the case. Will regressions indeed be spotted
fairly quickly? It often hasn't been the case. What started this
discussion was an observation that one had taken a long time to be
noticed.
That's not so surprising when we think through it - current work
varies, projects change and some get put on the back burner for a
while, so people aren't running every line of their code again
immediately on each DP version. Assuming all regressions will be
caught in a timely fashion, fairly casually just by sticking to the
current DP and that alone, is trusting a little too much in luck.
The whole includes the half - promoting a more complete solution is
not opposing a partial one, indeed it also promotes that piece. But
the more complete solution it is likely to succeed more often,
assuming that's the goal. For me that's an easy choice. Therefore:
Yes by all means, install the latest build AND an older version! :)
Best wishes,
Curry Kenworthy
Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/
_______________________________________________
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
_______________________________________________
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
