Hi Brian,

> Your developement time/beta of version1 is irrelevant to
> the user--especially the new users I suggest.

Well, it's not so much the previous development time that is a factor here, but rather that putting out updates requires me to do additional work with tracking new versions and possibly making new update installers and stuff like that.

It also takes a significant amount of testing to make sure that any changes do not cause a "regression" and introduce new bugs and problems instead of making things better. If something is released and is functioning in a very stable manner, it can be a very good thing from a development standpoint to not mess around with it.

It is basically not a totally simple process for me, it adds extra stuff to my workload and will actually take time away from new feature development.

So it is not something that really merits the time involved if the issues are not at a somewhat high level of impact, like a persistent problem affecting many people, stuff like that. A special feature for just one person's request just does not fall into this category - I'm sorry but those are just the cold hard facts.

It is a lot easier for me to put in these kinds of things _before_ the release is finalized. If you absolutely need stuff to be included with the full version release, it is more practical to mention it to me before the final release rather than after the final release... That works a lot better!

Please note that I have added in a huge number of such things (for individual people in many cases) during the beta release when it is easier for me to just roll out new versions all the time.

Generally it will be during beta releases that you can expect to get a lot of updates and dynamic changes in response to requests.

Once there is a finalized version, that final version will not generally undergo a bunch more dynamic changes, it will tend to be a lot more nailed down.

I know that may be confusing since it is such an abrupt change from the way the betas go, hopefully with this information you can get a better explanation of what to expect.

Also this kind of approach is only really possible since I shoot for an extremely high level of quality in that final release, so it is not as necessary to roll out all sorts of bug fixes.
That's a little different than what you may be used to with other software.

Would you prefer it if I rolled out a much less stable initial version that crashed all the time so that there would be a lot of updates following it? ;)


> but I can not help feeling that there are, at least a handfull,
> of problems that need an improvement in the very short time.
> As I have said before, maybe an SR1?

So far nothing has been reported that is significant enough to merit a service release.

It will be a lot more efficient for me to incorporate minor tweaks into v2 betas which should get going in not too much longer.

I'm sorry, but I just cannot totally throw out my own time and development efficiency considerations to the wind, I don't have unlimited time and only have 24 hours to work with in a single day... :)


> (Will V2 be in 1 or 2 years?)

V2 release will be about a year away from now probably, but the initial v2 betas will be available a lot sooner than that, hopefully not too much longer.

I appreciate the feedback! But there are a lot of factors at work here that may not be immediately apparent to an observer.

I can understand that from a customer's perspective that it would be cool to buy one version and then get all kinds of updates and new features without ever upgrading to a new version - but that is just not feasible for me to do from a business perspective, sorry!

- Michael