|
For me, it works like this:
* Alpha == 'technology preview'; feature set still in flux, some features may not work at all
* Beta == feature set for release defined; all features implemented and believed to be working, but there may be some open bugs
* Release Candidate == all features believed to work; this is essentially a an open field test. All bugs fixed (within reason).
Given those guidelines, here's the thinking:
Since I have this serious phone-network compatibility issue, it's still in Alpha. Plus, there are some other convenience features I want to get in; work on them being postponed by the more critical networking issues.
So, if all goes well over the next couple weeks with the phone fix, then maybe it will be Beta by July. Also, since it's been Alpha so long, there's been a lot of good testing. I would anticipate then that the Beta would go smoothly and perhaps have RC for v1 in about August. All this barring the discovery of critical new bugs of course.
Believe me, I'm eager to move it along, but I'd rather be conservative about pronouncing the quality/maturity level of the product.
Ultimately it's a credibility thing: if I set expectations of the quality/maturity too high, then folks will abandon it as junk and not come back at all. If I set the expectation lower, then they are more likely to say 'OK, it's Alpha, there's issues, I'll check back on the progress in a month or so and give it another whirl then'.
|
Login
Register
FAQ
Search
