Since we're rolling out some patches before the next release, I have now opened a patch file area as a subsection of the download page to keep fixed bugs and patch files in one place. Whenever there's a new bug that I get fixed, in the event that it makes any difference to our users, it will be added there.

90% of the bugs reported so far have been gracefully easy to fix (less than 15 minutes each) once I've gotten to duplicating and analyzing them. They are almost invariably one-file minor fixes. If you come across any problems whatsoever in using your system, please report it in the forums. Where things are found to be actually broken, we want to get them fixed right away.

I am not incrementing version numbers in the meantime, if only for the fact that I can't be bumping it every day I put out a little patch like the ones released so far (three patch files to date). Instead, I have included a text file indicating the build date in the zip files, and made a note of the same on the download page.

Bumping the version number with every little patch would accomplish patches rolled out less frequently, so this is being done to ensure smoothest possible operation for the largest possible audience without extra hassle. Hope this approach is agreeable for everyone.

This move goes together with the new "Flagged Bugs" feature that has just been rolled into the forums. You will now find it in the Forums submenu at the top right of the screen.

My hope is that this solution will advance:

1. Tracking of reported, investigated and resolved bugs
2. Ability to find solutions to suspected bugs faster
3. Decrease in time spent with duplicate bug reports
4. Level of attention to bug reports and faster resolution times

Please take advantage of this new feature and help us progress towards a 100% bug-free system. If you have other suggestions on how to streamline bug hunting in the current environment, please let us know. (The error logger built into iWiccle 1.20 -- see the error_log table in your database -- will be deployed shortly to aid in remote debugging.)

A few more thoughts on patches and release numbers, posted to a discussion elsewhere.

I know from my own productions that as a developer you don't really care to bump the version number every single time you patch a minor bug, because you might end up bumping it every other day which is a nuisance as well as confusing to some users who assume they have to upgrade all the time, and holding back on bug releases to pool them up for upcoming releases is an option that leaves some users with unnecessary minor annoyances, and introduces new users to bugs they shouldn't have had to deal with to begin with, since they were already fixed in the dev department.

What I've taken to is including the build version in a text file with a base version number and the build date, and while I update the release with minor fixes, I keep a separate parallel log of issued patches by date, which makes it easy for you to identify your build and see if there are optional patches you can apply before the next version (with all the patches pooled together) is released.

I find that this both helps you stay on top of bugs by tackling and patching them while you research and confirm them, it provides software users less minor annoyances with the release they download, and the enthusiasts who want to keep track of builds are free to follow the patch logs and the build dates. I know there are release purists who will never agree with the approach, but I find it an agreeable compromise between utility and integrity.