Seeking confirmation of a bug...

[Richard Gaskin]

Curry Kenworthy wrote:

 > Richard:
 >
 >  > Testing in older versions is a nice-to-have.
 >  > Testing in the version the team is currently working on
 >  > is a must-have.
 >
 > Catchy, but potentially self-defeating. This will catch the most
 > obvious bugs (and we already have that) but for regressions we need
 > comparison, and that involves looking at more than one item. (Or a
 > great memory.)

Two very different scenarios.  What you describe is what I often see 
Panos and others deliver in the course of resolving reports, identifying 
the source of origin of a bug.  As engine maintainers, that is indeed 
essential.

But most of us are scripters, more responsible for our work that relies 
on LiveCode than maintaining the LiveCode engine itself.

For us, if we encounter a bug all we need to do is to report it, along 
with the steps needed to see it.

If we use an older version of LC, we would also have the additional step 
of first running the recipe in the latest version to see if a fix has 
already been delivered.

Reporters are not required to trace a bug through all versions to 
determine if and when it became specifically a regression.  That would 
be an onerous requirement that would dramatically slow down reporting, 
and for many it would be so cumbersome as to discourage reporting 
altogether.

The history of a bug can be helpful if you happen to know it, but is by 
no means a requirement for using the bug DB.


 > How can people report a bug if they never notice it? People see these
 > things mainly when they are working between versions. That's the crux.

Not for me.  I don't generally spend much time reporting bugs I don't 
see. :)


-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com