I love consistency. I believe it is one of the primary reasons I was predisposed to be a programmer. Input X into a function and get Y in return - and get the same result every single time forever. Which leads me to the topic of the day: How do you upgrade software that you write? Releasing updates is a fine balance. Too many releases cause pain, and too few releases cause pain - just in different ways.
Let me start with my premise: All software is released with bugs (I'll concede that zero defect software exists, e.g. medical devices, NASA, etc., but that is not even close to the norm in the business world today). Some bugs are small, some are huge. Some you can work around, some cripple the usefulness of the application. Some are known, some are yet to be discovered, but the bugs are there. How do you address getting fixes to these bugs to your customers?
One method is to have rapid patches, addressing the most severe bugs first. I love this approach. It does come with some extra burden to make sure that your software is up to date with the latest and greatest software, and you may need to install several patches over the course of time, but I like the incremental approach.
Another method is to roll as many bug fixes into a patch and deliver less frequent updates. This is certainly better than no updates, but the end result as an end-user is that I end up living with bugs on my computer even though the vendor has fixed the bug ages ago (comparatively speaking).
So, the logical conclusion is that you like one approach or the other. If you like the first method, it is illogical to then turn around and question why this is being done (i.e. "What's wrong? Is the software too buggy?"). Of course it has bugs. See my premise earlier if you don't believe me. But the fact that the vendor is taking quick steps to address the bugs is a great thing. If, on the other hand, you prefer the second approach, then it isn't fair to criticize the length of time between the updates. Both of the complaints above are just a matter of degree. It is impractical, and dare I say, impossible, to do both approaches simultaneously.
Borland has moved from lengthy, all-inclusive patches to a model closer to the rapid patches. I see countless examples of people who used to deride Borland for adopting the all-in-one patch model now complaining that they are releasing too frequently, and that, somehow, it reflects on the quality of the application. Unfortunately, in business, money matters. Schedules are set, profit targets are projected, books are balanced, and goals are measured against the bottom-line. Rarely does a software product ship "when it's ready". It ships when management says it must ship. The developer's job is to make it as good as they can in that time-frame. I wish that would change, but that's not going to happen until the entire software industry realizes how that can impact their bottom line. So, my bottom line is this: While software from any company is not perfect, I love the fact that Borland is releasing frequent patches.