> > I understand this <g>, but I think that having a detailed list will help a lot in testing these "test" releases. I mean, if you tell me "I've fixed lookup control when there are just 2 records in the lookup table" I will try this with a lookup table of two records, and check if there is collateral effect in my app under this condition. Or, in any case, I will put much more attention in lookup behaviour. Or I can think about problems that I have and that can be related to a certain fix you did.
>
> Exactly, when I don't know, what to test, testing will be very difficult :-)

Writing the notes takes time, probably as much time as
finding and fixing the bug, and then you have to update the
manual <g>

Not an excuse, but I know how dificult it is to manage this.
I have a bug tracking system in place with my customers, and
this can take much more time to manage than doing the actual
changes requested. I've just spent half an hour converting a
program module for another application. Documenting the
change took 4!

Jason uses a package called Beyond Compare, which displays
differences between two directories of files. This I use on
my own applications when a problem comes up that we can
track to an earlier version, and you can display the
differences between that and the current build ( and usually
spot the mistake ). I also use it on the IBO code in the
same way - because I tend to jump several updates at a time
( Production is STILL on 4.2E <g> ). This throws up lots of
changes, but fills in the information missing from the
notes.

So please use the information available - Jason will get
round to some extra information - He has indicated that the
bug list is getting short, perhaps we can freeze IBO4 and
start looking at the next step ( Kylix? <g> )

So no more feature changes please - just bug fixes?

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services