Rather than releasing a big improvement, release them in small dosages, so that we all (including TS support) can track the bugs better.
I noticed instead you choose to release patches. But why not just release a new beta version with the patch included? In this way, we can test both the patch and any new features that have been worked on. This is how most software vendors do it.
In the "what's new" documentation, it should summarize the new features as well as the bugs fixed or improved.
I think this will reduce the 'withdraw' of waiting for a new release. It would also allow actual users to test new features and find the bugs earlier.
For example, there will be support for OEC data feed, multiple core processors, fixed drawing tool errors, existing data feed gaps, etc. Why not release a beta after each of these fixes or every other fix so that users can evaluate whether the bug was fixed to their satisfaction? And also test newer functions?
This may also keep MC more focused on quality. I like the fact that MC wants to do so much. You are leaps and bounds above TS in that you actually do try to implement requested features quickly But one concern I've noticed as well is that once you release a new version, you will then focus programming effort on a new feature vs ensuring current features are bug-free. The improvements aren't noticed as much when there is so much time between releases, as we try to build up workarounds for the previous bugs. We have to get rid of those workarounds, and possibly build up for the next workarounds.
Having features that work properly is just as important as having the feature itself.
![Wink ;)](./images/smilies/icon_wink.gif)
Releasing new betas more frequently would help us > help you > help us test out new and existing features more thoroughly.
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Your thoughts please.