I said I’d have the new release available for the Beta Test Team on January 2nd, and I made it! But just barely. It was up, but I didn’t finish the email informing them of its availability (nor of its secret location) until almost 12:03am of January 3rd!

There is a fresh bug in Mori v1.6.8, so this one now in testing may go official without all the features I had promised, but I’m sure you’d rather have it lacking those features and working than to use the buggy version and wait for all the new fixes to be incorporated in v1.6.9.

Speaking of new fixes, I might add some more drag and drop capability as the lack of dropping groups of files, or folders, or even JPEGs into the source and entries view is seriously hampering productivity for a lot of us.

Anyway, we’ll see how this test version works out. I’ll try to add those other fixes, but when the latest incarnation of the empty window bug is fully squashed, I’ll release it with whatever fixes are completed and begin adding the rest to v1.6.10.

As I was reviewing the code changes I had made, I slowly realized that the Mac’s user preferences system had a minor philosophical flaw which makes for dangerous situations in the program.

One of the goals of this version is improved recovery from faulty stored values relating to the preferences and UI, so you can continue with only minor inconvenience and perhaps a need to again set preferences to your liking. Not adequately performing this resulted in some of the missing toolbar and empty window problems that were experienced before. (For a more exciting example of cascading faults, read about the 2003 Northeast blackout.)

So after some delays in getting the unit tests for this new component to execute properly, I’m now adding that component into the program. Once I have the Cocoa preferences system replaced, I’ll be releasing 1.6.8. Then I’ll work on the possible fix for the SpotLight ‘odd name’ bug for a quick-turnaround (later today) 1.6.9.

If that particular bug can’t be quickly fixed, I’ll work on some other long-standing issues in Mori for an update that will be released after a few days.

Incidentally, Tobias had a valid concern regarding the update process: “Where does testing feature in this? In olden times an update was a build with only known problems since a few people played with it for a week before it was awarded a version number. WebKit offers a choice between bleeding edge nightly r1234 and release 3.0.”

I plan to continue to rely on the Beta Test Group for testing updates, with a release candidate at least one version ahead of what is shipping. However, at the time of this writing there are 320 open bug reports for Mori, even after having pre-release testing candidates as part of the process. That just isn’t right.

I’m primarily depending on the unit tests to prevent shipping defects to you. They serve to expose bugs in existing and new code; and by adding tests for the types of bugs identified in the bug reports, the tests will continue becoming more valuable to the release process.

The purpose is to continuously speed up the process by improving its results. It shouldn’t be a shock when a program works right off the bat. The delays are (partly) associated with having so many steps of repeated inspections on the same system. It multiplies the time it takes to get a new release out the door. The less I tolerate it, the quicker it gets done correctly.