Slashdot Mirror
What constitutes an Alpha-version?
jacobm writes "An article went up on mozillazine.org yesterday in which the Mozilla team asks the community: what will it mean for Mozilla to be alpha? Probably a good question for everyone to think about, especially those of us who develop (or will develop) software for fun or profit. " Interesting question, especially when it comes to Mozilla. With M12 coming up, they are getting close to that stage, and have setup a criteria they think works. Do you agree?
You see, this, as everything, is a question of compromise. Do you want to wait another few years until they can get it absolutely perfect without any outside help, or do you want a pre-release that will be widely circulated so that they can see how the code in its current state stands up to real-world use and abuse, potentially accelerating the bugfixing by several orders of magnitude?
Your comparison with machine shop equipment is bogus. Downtime on such gear is extremely expensive and nearly intolerable. If your browser crashes, you sigh and kick it back up. Nevertheless, I will agree that an hour MTBF is completely unacceptable for a true release. Fortunately, thanks to open source development, it doesn't have to be.
And please, it's "horribly inadequate". Isn't it embarrassing to put glaring spelling mistakes in bold?
Steve 'Nephtes' Freeland | Okay, so maybe I'm a tiny itty
I believe that if this number is moved up NOW,in the alpha phase, it will become even better in future releases. If that number is left where it is, I garantee you that the MS FUD machine will pound that point hard and often. Let's not give them that stick.
Stability (User:it just works) is a shining downfall of IE and and the micros~1 platform. We should aim to be better than that. It's this focus on stability that has gotten PERL, Linux and Apache to where they are today, and I think the Mozilla team should use the same idea.
I'm not asking for 'four nines' in an alpha version, but there must be some middle ground somewhere.
pre-alpha means programmers only (and just for bug testing).
Alpha means it goes to internal testers. That can either be professional testers, or other engineers who have not been involved in the project before. This is where you find 'brown paper bag' bugs that seem to only be findable by people who DON'T know the internals of the software.
Beta means the testers aren't hitting bugs anymore during test use. Now you put it into actual use, but don't bet your life on it. More experianced users may be included here.
In general, each stage should repeat each time bugs are found. So, you release a first beta, and bug reports come back. The bug fixes go in, and are tested by the programmers, and then must pass through 2nd alpha. Once it can pass 2nd alpha, you have the second Beta release. That release can either become gold (1.0), or go through the loop again, depending on the type and severity of the bugs (only small ones!). Note that a 1.0 might still have mis-features, and missing features (that were not planned, there are features whose need was not anticipated by the designers) but shouldn't have bugs (it will since there's no such thing as 100% assurance, but that's the goal anyway).
mis-feature = 1.it does what it's supposed to do, even if it's not what the user expected.
The terms are a little harder to define for Free Software than for commercial, since many beta and gold users will mis-identify themselves as alpha testers. There is a much blurrier line between the phases since you can't define it by who writes the user's paycheck/ what department does the user work in.
Many of you will note that the standards described above would mean that a great many version 4.01743619746 commercial products out there are actually more like 4th beta.
I'm not disagreeing. But as I've seen it used currently the distinction is:
Alpha means the feature set may change before release.
Beta means the feature set is frozen.
That's very slight distinction from the above definition - features may also be eliminated.
Of course, alpha is also earlier and expected to be more buggy than beta.
Alpha is to get it into people's hands when major chunks are known not to be working - both to debug the things that are there and to debug the choice of features and the interface to them.
Alpha isn't just a matter of missing features. Sometimes a feature turns out to be a "misfeature": confusing, counter-productive, or actively hazardous. Sometimes a feature is redundant with another, and may be dropped in favor of one that is easier to use, or more powerful and general. (And sometimes a redundant feature will be added as a simplified shortcut for the more general feature.)
Between alpha releases the user interface may be significantly thrashed or even totally replaced. Even underlying communication protocols and file formats may be modified or replaced.
At Beta the choice of features is frozen. The interface may change slightly (be "tuned"), but this will normally be minor tweaking rather than a significant change in appearance. Protocols and file formats have assumed their final count and basic form, and may even remain compatable between releases.
But don't count on it. During Beta the hope is that everything is there, frozen, but probably needs bug fixes. But if there's a really serious problem with something, there might be a thaw.
Essentially, the difference between Alpha and Beta is management intent: In Alpha, design suggestions might be considered for V1. In Beta, they will generally be ignored - but might be considered for V2.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
1. Quality: Mean Time Between Failures should be at least 1 hour. The MTBF for the M11 release was 1.09 hours according to talkback reports (the "fullcircle" in (LINK) means that build reports crash events via a "talkback" component).
That seems reasonable and have achieved this with certain builds.
2. Architecture: Alpha should be "almost architecturally complete". "Almost" is a recognition that there will be some exceptions; it's not an excuse for large design holes.
"Architecturally complete" means that all public XPIDL interfaces have been reviewed for correctness, completeness and aesthetics; and have then been blessed by mozilla.org.
Well yeah sure. I wish their interface defaulted to a less color oriented theme. Wish that fonts were more happening and consistent with the other browsers as well.
3. Acceptance: There's a consensus in the Mozilla community that M12 is usable. Ideally, a majority of M12 users will try to live in Mozilla as their primary browser and mail program, ane restart it when it crashes. We don't want to set an unrealistic goal just yet, but we will measure and poll after M12 is out, in order to decide whether it was in fact "usable".
Sure.
Call it alpha! Pitch in, people, the lizard is getting close!
It'll have developed large areas of silver hair on its back, amass several females in a personal harem, and keep the others in line with displays of violence and aggression, sometimes ritual and sometimes real.
Oh, I'm sorry. I thought the question was about what happens when Mozilla becomes an alpha male.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
Speaking of Greek, traditionally "alpha" was the designation applied to something that's little past the prototype stage, and sometimes, is nothing more than that. It doesn't refer to the propensity for bugginess, but rather to whether the interface is decided or not. And in the case of alpha, it's not. The interface can change completely in later stages. Parts may be missing. Parts may be added.
In beta, on the other hand, we're done with that. Beta is the stage after which functional changes are forbidden. You can't change the interface in the jump to production. Everything must behave as documented to behave. All you can do is fix bugs. No new features. No change in calling conventions.
I have actually seen "gamma" releases, too. This seems to mean "We hope to God this is production calibre."
After beta--or rarely, after gamma--comes production. Never issue deltas, except in the form of a patch. :-)
Seems to me that the Linux model of devel tree and stable tree is much more appropriate. When Mozilla is ready to start a stable branch (and it's getting fairly close), then I think that's what they should do.
Leave the "alphas" and "betas" to the Netscape Communicator crew.
Interested in XFMail? New XFMail home page.