What constitutes an Alpha-version? 121
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?
Alpha definition (Score:1)
PreAlpha : Very first code written, this is where initial loaders, etc. are designed and tested as well as the other basic parts of the code. (typicaly Stability ~ 0)
Alpha : The thing at least runs now though crashed are expected. :-) the feature set is not yet complete, this is where the project begins to take place as interface issues are addressed and features take shape
Beta : Feature freeze, Most features are intact, though there are normally still a few that are still being ironed out this is normally where testing really begins to pick up, to squish all those bugs.
Release : The bugs have been all but ironed out now, though there really is no such thing as bug free code, so a few are hiding somewhere, but it's good enough for everyday use.
(By this, Mozilla probably sits around Alpha)
Chris
1 more thing for Mozilla alpha (Score:1)
Was there not a big war about
Think about it from this future perspective...
"Why should I download Mozilla to replace IE?"
"Because...
It's 8 megs instead of eighty, making it small enough to zip across 7 floppies.
It is rock solid.
It is fully HTML 4.0 compliant
has complete .png support"
Users will want it, Developers will need it.
Could you picture a world ruled by IE, IIS, and front page?
The totaly befuddled web developer replies to you, "I don't understand. What do you mean you want to view the source?"
Re:It's all Greek to me (Score:1)
Re:MTBF=1 hour? (Score:2)
I work in the machine tool industry, where MTBF is measured in thousands of hours.
Consider what's acceptable, given the target market for the product. A Web browser doesn't need thousands of hours of uptime, or even tens of hours -- for one thing, Windows will crash sooner than the browser will, anyway. :)
Unlike a piece of machining hardware, a Web browser is not something that people will use all day, and depend on to get their work done. As applications move from the desktop to the Web, ....
Errr, wait a minute...I just realized something...
River deltas, code forks (Score:1)
Define "Alpha" (Score:1)
Are these not the real definitions?
"Dee herr, dee dur hurr, m0rt! m0rt! m0rt!"
-The Swedish Shef
Re:Alpha? What we really wants (Score:2)
Well, that's not how it's done these days. (Score:1)
The nastiest ones I have seen so far are the web application servers for UNIX. They must all be pre-alpha when released, especially the Sun NetDynamics server, which apparently likes to take a dive on whatever OS it is running on a regular basis, IN RELEASE AND AFTER SERVICE PACKS. No wonder they cluster them. Or they give you instructions as to what machine directives or functions to AVOID using. Silverstream, Bluestone, and the Java web server aren't too much better. And they are in general release! The scary part is that this is another product of the Sun/Netscape alliance that we had some Ex-Sun guy talking about like it was better than sex. Having to reboot HPUX, IRIX, AIX, or Solaris boxes because of memory leaks is a BAD thing.
Microsoft - Let's not even go there. We know. Why beat a dead horse.
However the point is that it's no longer standard practice to release working code, apparently. Testing is not being done (and I've seen quite enough supposedly final applications to prove it).
Open source is a different story though. It gets released as alpha or pre-alpha code, and it eventually works because the code is out there to fix it. Also, people are more willing to submit bug reports because they know they'll get fixed.
Try that with Sun or MS. It gets dumped into a bit bucket unless it gets posted to BUGTRAQ or NTBUGTRAQ as being a security flaw.
Still, we have companies out there who are trying to meet release schedules set by the Stef Murkys of the world who release code without testing it as well as they should have.
In my opinion then, the only good product out there in the alpha stage is Linux, which always is in one because it's a continual work in progress. That is not a bad thing. There are stable versions of Linux that are in release, however Linux as a project will always be, which is good
Re:Alpha, Beta...let's call the whole thing off. (Score:1)
Re:It's a trade-off (Score:1)
Well, it's kind of hard to compare data here. When you say "days at a time", what kind of days are they? Hour upon hour of frantic link-clicking through all kinds of weird-ass CSS2/HTML4/JavaScript whatever sites, or just reloading Slashdot every 30 minutes?
They're using FullCircle info from their milestone builds, so I guess their metric is one hour of "average use" -- that is, the average use by people who like to run pre-alpha browsers. I would guess that means more stressful use than normal.
Steve 'Nephtes' Freeland | Okay, so maybe I'm a tiny itty
Re:Alpha (Score:1)
Stan "Myconid" Brinkerhoff
Machine tools (Score:2)
I doubt the MTBF of those machinese you're using would be so high if they didn't cost anything to replace (in cost or time lost)
--
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
Re:Normal Use (Score:2)
Open Source Devs Discuss too much??? (Score:1)
Alpha stage vs. Beta Stage (Score:1)
Beta software is feature-complete, but lacks the testing and refinement that needs to go into gold releases. By gold I mean a program that has met whatever metrics that were set out at the beginning for stability and compatibility.
Note that these definitions require a structured development plan, which I think many software pieces (mostly on the Windows platform) lack.
As for stability metrics, I think the 1 hour MTBF for Mozilla is a little low, but then, the developers in charge consider that alpha software.
Re:MTBF=1 hour? (Score:1)
Actually, if it worked for an hour straight, Micro$oft would try to add some new bugs...
Re:A-L-P-H-A, ..and MTBF (Score:1)
Re:Alpha? What we really wants (Score:1)
Everything is explained at mozilla.org
narbey
I thought it was alpha. (Score:2)
My idea of the definition of alpha was something like "it runs on my computer, and if you're lucky it'll run on yours too".
More generally, it would be a piece of software that should be a usable product, but may be lacking some features, experience crashes, or not work at all, but you knew that when you got it.
Obviously I'm wrong, since (a) Netscape feels the need to call Mozilla "pre-alpha", and (b) my definition would include all versions of Windows.
--
What do you want to accomplish? (Score:1)
I think that the real question is: what do you want to achieve by labelling your software in some way? When you label your free software project as being in alpha, when mozilla.org labels Mozilla as being in alpha, what do they want to happen? Once you, or they, know that they can set the various code goals.
It's a trade-off (Score:4)
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
Clear, except wrong (Score:1)
Alpha: Ready for internal testing
Beta: Ready for external testing (i.e., outside the lab)
Release candidate: Feature complete, and if no serious bugs come up after a certain amount of time, the software is released.
"Gold" has also turned up in recent years, which means released to manufacturing.
Re:Alpha? What we really wants (Score:1)
And as someone else said: you want tommorow's browser today!1. XUL is good. Trust me.
2. You can use the engine.. for your own browser.It will be done.
3. Mozilla does not memory leak that badly, and it's getting better.
4. Now is unreasonable. However alpha will lead to more uptake and as a result, more bug reports / fixes.
Traditional use (Score:1)
But it doesn't seem like this is how the article is using these terms.
Re:A-L-P-H-A, ..and MTBF (Score:3)
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.
Tough call (Score:3)
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.
Feature change (Score:3)
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.
Re:It's a trade-off (Score:2)
Re:Must question this claim. (Score:1)
Depends on the definition of failure (Score:1)
Re:Must question this claim. (Score:1)
Bad Command Or File Name
Bazaar Design (Score:1)
-- John
P.S. Your homework is to find all of the Ph.D.'s you can in the above, and convince competent grads in the appropriate fields to write them. 8-)
MS and Delta software (Score:2)
After W2k beta release there was RC1 and RC2, just another name for Gamma1 and Gamma2, right?
After RC1 and RC2 we should have Win2k, which is another name for Delta, right again?
And after you have the final release, calle dSP something by MS.
The biggest difference between the different alpha/beta/gamma/delta releases is the price of the beta (or gamma, or whatever).
cultivating ignorance (Score:2)
Once we've done that, we start adding in mood. "If only he weren't so ignoraretur!" :-)
Re:MTBF=1 hour? (Score:1)
Alpha being the key term. The reason the MTBF isn't thousands of hours yet is because it's Alpha Software. One hour mean uptime is good enough to honestly run it through real world tests and find the bugs.
The criteria is not 'inadeqate' as the case may be. It's not release software. I'd complain if the MTBF was an hour and it was being called Beta. But it's not. So yes, you are off base =)
Re:[Already OT so...] That commie logo! (Score:1)
I don't really know if it is scaring people away - I think its a brilliant pastiche - a combination of Russian mid-century art styles, bad Japanese sci-fi movies, and modern computer technology. If people are so incredibly dogmatic that they are frightened by a simple logo, maybe they should stand up and say so. The logo is wonderful satire, if you ask me. Satire is often lost on the dogmatic or narrow minded. Just think of what Mozilla really IS, not what the logo reminds you of. If you don't get the joke, its really too bad
Cheers
Eric Geyer
Re:MTBF=1 hour? (Score:1)
I pointed out it was a Browser, so it has to munge through reams of horrible markup code, that may or may not conform to spec. It may or may not contain extensions. Browsers are hell to write because they're expected to make a webpage out of pure garbage code. GIGO (Garbage in, Garbage Out) isn't allowed to apply.
Re:cultivating ignorance (Score:1)
Re:It's all Greek to me (Score:1)
Don't forget the dual. Greek had a dual, too, besides the singular and the plural. And you can get people really staring at you when you start speaking of ``one criterion, two criterio, three criteria''. (Apologies — I mean, speaking OF ``one criteriou, two criterioin, three criterion''.) That's what happens when you speak to ignoramis... ahem, to ignorant people.
Oh, and for some of the other posters, the plural of ``alpha'' is... ``alpha'' (and so is the dual, and so in every case).
``Græcum est, non legitur'' as they used to say (it is Greek, we don't read it).
Re:It's all Greek to me (Score:1)
Re:Clear, except wrong (Score:1)
I develop multimedia CBT. Our testing is internal and with SME's (Subject Matter Experts) throughout development.
At alpha, the product is realively 'ready' and undergoes overall usability and tech testing for a week with internal folks not assigned to the particular project, and with SME's as well at the location of their choice.
At beta, the program is ready to go 'live' in our opinion, so we give it to a sample of the target audience. We allow 1 week for their review, then 2 weeks to implement changes/fixes they find/suggest (SME's being pretty much the last say on that, unless it's out of scope for the project).
Once those changes are made, SME reviews final and signs-off, and product is 'gold'
Re:MTBF=1 hour? (Score:1)
Re:MTBF=1 hour? (Score:1)
The desirable MTBF is a function of the cost of the failure relative to the marginal cost of further improvements in reliability. For machine tools, a single failue is very costly involving damage to persons and/or other tools plus downtime for the line. MTBF rates in machine tools could probably be extended further by the use of exotic materials, but wold they be worth the additional costs?
In end user software, the costs of a single failure are much lower -- the user restarts the software (or in the case of Windows, reboots the PC). An excessive failure rate will cause irritation in the users, so your failure rate has to be low enough so that users don't want to switch to other products. Average MTBF rates in the tens of hours may be acceptable for some end user software (but not for OSes).
bacteriae ??? (Score:2)
hawk, who learned to be careful about greek & latin endings when taking classes from Jesuits who were fluent in both
awe, noone else got it (Score:1)
Alpha, Beta, what's in a name (Score:1)
serious functionality seems to be lacking should
it be added at this state before the software
goes to Beta stage. Beta is for bugtesting and
stability testing.
PvdS.
Alpha is a state of mind. (Score:1)
Originally, Alpha meant not feature complete, but most features are there, while beta meant feature complete, but still too buggy. And then 1.0 means "There's no bug I swear, really, honestly, it's fucking stable! And BTW
--
criteria from that article (Score:3)
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's a time thing (Score:2)
Alpha v Beta (Score:2)
Beta is the stage where you have stopped adding features and are just working on clobbering bugs.
Alpha (Score:2)
I'd say the last Mozilla release was pretty much there.
The way I figure... (Score:4)
Oh, I'm sorry. I thought the question was about what happens when Mozilla becomes an alpha male [expectation.com].
Alpha version is... (Score:1)
I'll get flammed for this..but....does that mean Linux is an alpha
Alpha Condition (Score:2)
First, you have pre alpha state of software. Pre alpha testing include basic system stability, individual feature testing, and system testing, where each feature, as well as the whole system, are put through basic tests that would be considered "normal operating conditions".
After this testing is passed, alpha state is declared.
Then beta testing involves major tests that test the limits of the system; a lot of non-standard situations that the software should not have to encounter (but will, for any number of reasons).
If beta level is reached, then we released the software to our clients; and the rest of the bugs that slipped through the cracks are patched.
This clear?
Def. of ALPHA (Score:1)
--I think M12 would fit under this if they worked out enough bugs to make it preform at almost a production level. A.K.A. it can't crash very often for simple tasks, and the user interface has to be acceptable. If you build it they will come.
Re:criteria from that article (Score:1)
Re:MTBF=1 hour? (Score:1)
That said, I think we're becoming much too accustomed to improperly debugged and unstable software.
MTBF=1 hour? (Score:2)
Wha?!?!?! an hour?! . .
Now please allow me to preface my comments with where my point of view comes from. I work in the machine tool industry, where MTBF is measured in thousands of hours.
Am I just off base? or is this criteria horibly inatiquit. Even for an Alpha.
Re: (Score:2)
Re:It's all Greek to me (Score:2)
That criterion and phenomenon, or bacterium and millennium, shall someday undergo more complete assimilation is far more likely a question of "when" than it is of "whether". As this occurs, strange corruptions like double plurals sometimes arise and occasionally persist, such as the "these bacteriae" example I read and recoiled from the other day. What's next, "millennias"? :-(
All you really have to go on is your ear, but checking the OED never hurt anybody. :-) And at this time, "criteria is" seems just jolting an error in numeric concordance as "pathos are". Yes, Greek sucks in its complexity. And English is annoying in its unpredictable assimilation strategies. But you really aren't going to change either. That's just how it is.
To make this posting useful and geek-relevant, you might check out Perl's Lingua::EN::In flect [cpan.org] module. It's filled with boatloads of examples of these.
ObFunny: How many Germen [sic] does it take to change a language? :-)
Alpha (Score:2)
Beta = code freeze. All planned features are working for typical and atypical use, as far as testing can determine. Testing has run coverage tests, and can't find any crashes or surprises. A cautious release could be made, with a "we think it's good, but what do we know about you crazy people" label firmly attached.
Release = No show stopper bug reports have come in in several days or weeks. All other bugs are trivial or border cases, though if time and market permits, you'd like to nail them too.
Stable = It's been in production use for 2 times the typical use time* and no one has complained.
*Typical use time varies as the the product. For a game like Quake, I'd say this is at least two nights of serious muliplayer gaming, plus a couple of weeks for people to do a full feature discovery. For something like Linux kernel, it's several months of production use. For a CAD/CAM program, it's a few real projects from start to completion.
Re:It's a time thing (Score:1)
I agree with this definition of Alpha and Beta. (Score:2)
The worst thing that could be done is to release a premature and buggy product - that would kill it surer than if Microsoft bought AOL.
why Greek? (Score:1)
this is a silly post, so moderate it down if you feel the urge.
thanks
Re:why Greek? (Score:2)
Re:Bazaar Design (Score:1)
- For a project on the scale of Mozilla, can we realistically expect non-core developers to be useful in "early" stages?
- Is the previous question just a fancy way of asking: What does "plausible promise" really mean in context of various projects?
- How many open source developers really have the skill sets required to participate in Mozilla (a large OO design and implementation project) in the early stages?
... which in turn begs another important question: - what are the "skill and competence" demographics of open source developers?
- What are all of the project characteristics (stage of development, project scale, community perception of project, community perception of core developer(s), PR, licensing, etc.) that affect the success of drawing in qualified developers to the project?
Dude, a bit sleepy to reply to each point above, but... OK, I never could resist a test:- Only in the terms of requirements gathering and suggestions for code style (see yourself as the customer *and* sustaining-developer).
- Yes, although IMHO, bugginess and plausible promise are semantically divergent enough to be considered two criteria.
- see next
- Either I am utterly idealistic here, or just seeing things differently. I think that we experience a network effect in OSS for both debugging and distribution of workload. The critical key in any OSS project is the synergy brought on to the team, which is entirely key on the project management. Thus the implicit independency from godlike coders, and a premium on communications skills like feedback, comments, etc.
- Need more data...[this questions sounds very much like MBA material]
P.S. Your homework is to find all of the Ph.D.'s you can in the above, and convince competent grads in the appropriate fields to write them. 8-) Neved did homework. Just aced the tests and set the curve for the finals.one hour? yikes. (Score:1)
Netscape 4.x works for an hour at least on my box normally... and most of the time only crashes when i close one of the windows.
I'd like to see at least 3 or 4 hours uptime before a crash - even in an alpha. For me, stability is a pretty big thing. I think that 2 hours should be minimum for an alpha. 2 for an alpha, 10 for a beta, and at least 24 for a release. That makes sense to me. The final release should be able to take the longest period of use that any geek can throw at it, which is probably about 24 hours. hehe. Personally, I'd like to see it as stable as the kernel with an uptime of 400 days... but am I being fair?
Another feature that'd be neat to see from a netscape kinda product is fault tollerance. IE will display even garbled HTML fairly right... whereas netscape will half the time decide not to display it at all (esp with frames) I know its nice to have the browser tell u where u screwed up, so maybe it should be a fault tollerance level switch or something? Some kinda syntax checker dialog? That'd be good for developers and for users. A user doesnt want to care if someone didnt type his html right, so fault tollerance would be good for them
Re:It's all Greek to me (Score:2)
From TNHD:
Personally, even before I read this, I went with the definition described by the B-Test. For me, this means the first version of the software that functions according to the original specifications...or the first version that is basically functional. Its hard to say where to draw the line with the Bazaar-style of development, since this line could be drawn at many points in the development process.
In my experience, where this line is drawn is often more political than technical, especially if money is involved.
Re:Alpha, Beta...let's call the whole thing off. (Score:1)
I'd say it still applies for each step of the process -- alpha and beta are just ways of describing the evolution of each release of the product, development tree or stable tree.
Alpha: The developers think it's done, more or less.
Beta: The testers think it's done, more or less..
1.0: The users think it's done... more or less..
1.8.3g: It's done. Time to start on the 2.0 release. :).
Re:Alpha, Beta...let's call the whole thing off. (Score:1)
It's just a different way of labeling them, perhaps simpler than the odd/even number that sometimes confuses newbies.
Re:MTBF=1 hour? (Score:1)
I tested mozilla for a while and in the later versions (before and after M11) I could break it within 30 minutes. (Sometimes it segfaulted in less than 10)
Re:Bazaar Design (Score:1)
The problem, IMHO, is not so much the size itself... it's rather modularity of the system. Most OSS project are either small-scale or have been designed from the beginning to be very modular, with *very* small module scale and limited module interaction. This means plugin/component architecture from the very start, and constrained interface complexity (i.e. it's predecided that components use VERY simple protocols to talk to each other).
Mozilla, currently, seems to have moved in this direction - it uses XPCOM and has IDL interfaces to all its internals. Unfortunately, it wasn't this way all the time, and the original monolythic Netscape sources were not merely daunting, as Mozilla's are, but nearly unworkable for the outsiders.
After the rewrite of the entire system, things cleared up a lot - Mozilla's internals are pretty close to Mnemonic's (the OSS browser designed for modularity). Unfortunately at this point (early 1999) the browser fell long behind schedule and so rumors of its early demise became prominent. Lately, however, there's been a noticable influx of the external developers to the effort - precisely because it's beginning to look managable.
--
Alpha means... (Score:1)
The definition of Alpha varies largely based on the problems facing the project. Some projects are very stable (even in development), but have large architectural holes. They may do an Alpha release that has some pieces missing and request ideas for additions.
Mozilla is quite the opposite. While some functionality has yet to be implemented, my opinion is that the focus has been too much on features and too little on stability. You *won't* get all the bugs out of a program if you wait until the last minute to pack them out. That said, I think Mozilla really needs to do a two milestone FEATURE FREEZE, work out hoardes of bugs as quickly as possible, and then release an Alpha version. Sure, there'll be some elements missing - fix those while people are poking at the first Alpha. Then release a second Alpha integrating the stability fixes and the final features.
Finally use the data out of that to move on to beta...
I think the Mozilla project has a long arduous bug war ahead of them that has been sub-consciensly avoided for far too long (though M12 is a *step* in the right direction - esp for Windows and Mac).
LOSE THE NON-GTK MENUS ALREADY - THEY SLOW THE UNIX VERSION DOWN AND MAKE IT CRASH!
-nullity-
Alpha=25%, Beta=75-95% (Score:1)
In commercial software dev, you only have 3 variables to play with - time, quality and money - and changing any one of them changes the other 2, meaning that the feature-set of the final software is often fluid until shortly before shipping. And so, as well as being arbitrary the labels cover a blurry time/feature-set.
Which means that the alpha and beta definitions should be defined in a way that is useful to your project and set of circumstances. In my projects I use the entirely arbitrary, blurry, grey defintion that an alpha is one quarter of what I think will be the final product (chiefly driven by amount of time that the money variable can sustain) and a beta is three quarters.
Typically I'll declare something alpha when it is still feature incomplete but the main elements of UI are there, the key features have some (incomplete) implementation. But the implementation as it stands is reasonably stable - i.e it can be used, but don't trust it.
By the time I declare beta 1 I expect to be three quarters through development time, I expect the UI to be near-complete, functionality to be at least three quarters finished (but typically I expect it to be 95%). (Remember that time and functionality definitions are fluid though, because of the 3 variables.)
I expect usually to go to a beta 2 and sometimes beta 3. Beta 1 is usually for internal use. Beta 2 can go to trusted customers. Beta 2 has a frozen UI. Beta 3 is for general preview - often used as a marketing tool.
I know I have reached ship-stage when the software contains no known bugs that cause data loss. It will contain some known low-priority bugs.
Re:Release Candidate (Score:2)
But for Microsoft products, release candidate == pre-alpha.
Defining alpha (Score:1)
It's all based on what you call a beta. Alpha is "the stage before" beta.
Microsoft has no alpha they go directly into beta.. at least from what I have seen. They break down the beta into stages but they call it all beta posably for market reasons. It dosn't mean they don't do critical stages of testing mearly they call all the stages "beta". In some ways Microsoft earns some ridicule for saying "it's only a beta" when a Microsoft beta dose something a beta shouldn't do.
But what IS a beta?
One online game defines a beta as a basicly stable product that needs some premarket testing to get at the hidden bugs.
A gama test is a "specal" quality test that is really not needed but when done insures a higher quality not usually found in powerful software products.
A gama is a test of a "production" or "releace" quality product just to find those really annoying hidden bugs.
I like that deffinition...
This leaves Alpha as the first stage tests. Unstable and posably unusuable but the hope is a product enters an alpha test phase as a stable usable product. The Alpha isn't just a proving test like Gama it's to hunt down why it isn't all it is in the lab.
Alpha is also a test to see what is missing. It's great on Linux FVWM but Linux KDE has web browser enhancement features it could take advanatge of.. thats the kind of thing that can show up in a gama test as well but Alphas a good place to bring that out.
Thats how I define a beta but I know others don't and I live with that.....
Re:It's all Greek to me (Score:2)
Re:It's all Greek to me (Score:2)
Re:It's all Greek to me (Score:1)
The terms aren't rock solid, but... (Score:2)
And a beta would be when it's stable enough to send out for user comments, not be necessarily stable enough for them to consider using regularly.
I'd call Mozilla a late Alpha, or early Beta now.
The terms have gotten twisted in the last few years, mainly in my opinion, by Microsoft. MS has had OSes at a nearly-ready stage for years, and uses Beta to mean, it's done, but if it crashes, that's cause it was a Beta.
To me, a beta is something you don't run on anything mission critical. I wouldn't use a truly Beta OS on even my PC.
So, I think Mozilla is in Beta now, or would be if the terms hadn't changed to justify clumsy bloatware.
Alpha? What we really wants (Score:1)
State of the code (Score:2)
- Pre-alpha: Partial features. Still under serious development.
- Alpha: All major features work most of the time. May be missing some chunks, and/or may not work under some circumstances. May not cooperate nicely with other programs. Beware memory leaks, non-standard configurations, etc.
- Beta: All major and most minor features work. Some bugs under particular configurations. Some "we don't know why" bugs still being ironed out. Developers are looking for configurations / situations where stuff blows up.
- Release: All features work, except perhaps in uncommon configurations. Bugs (hopefully) are minor.
This, of course, is in an ideal world==================================
neophase
It's all Greek to me (Score:4)
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. :-)
Re:Alpha v Beta (Score:1)
Alpha version is something that will crash, Beta version is something that may crash, Release version is something that shouldn't crash.
Al.
--
Alpha (Score:1)
Re:MTBF=1 hour? (Score:1)
> Am I just off base? or is this criteria horibly inatiquit. Even for an Alpha.
Hey, if it worked for an hour straight, Microsoft would release it!
[OT] How Bazaar... (Score:2)
When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future.
Question: Does this mean that projects going open-source should be Alpha stage before recruitment begins? If not, then what stage would you call it when your project is ready for open-source?
Disclaimer: I am a /. newbie, so point me in the right direction if this question has already been asked...
Re:MTBF=1 hour? (Score:1)
=)
My definition (Score:1)
- all requested features implemented
- there are known bugs preventing operation in 10% of cases
Beta:
- no known bugs
- code not rock-solid
- should operate in 99% of cases
Release:
- Rock solid, bugs apear only in special cases not though of during development
hehe.. alpha =.. (Score:1)
beta = something which is somewhat functional and can be used fi you dont mind the odd crash or misfeature..
smash
Re:Alpha? What we really wants (Score:2)
Re:It's a trade-off (Score:1)
Zontar The Mindless,
Must question this claim. (Score:2)
I'm afraid that you'll have to justify that claim to me a bit. As I see it, early releases grab attention, buggy or not.
This may be the psychological irony: tiny frustrations and aggravations, coupled with the promises of better things to come, *engage* the consumer with the product in a way that promotes it. A seamless, flawless experience is - dare I say it? - forgetable. If you make it look too easy, people will think that it is.
Aside from the obvious example (Microsoft), I can think of a couple other products that fit this pattern, including Gnome.
Now, I definitely don't think this is a good thing (I don't believe that humans are essentially rational, and the people who act on that basis - i.e., the advertising and marketing industries - seem to be thriving quite nicely), and I would like to be proven wrong. Can you name any historical product releases that showed how patient attention to detail is rewarded in the mass market?
Re:It's a trade-off (Score:1)
Actually, I run Netscape 4.x on Linux for literaly days at a time. Mem footprint grows and grows, so I restart it if it sucks up too many resources. But it doesn't often crash and burn.
4.x is 'fairly adequate'.
ebw
Re:It's a trade-off (Score:1)
Just my two cents.
Re:It's all Greek to me (Score:1)
Well, sure. Bacteriae are multiple groups of single-celled organisms. And bacteriaes are when you have more than one of these collections of groups.
:)
Re:Alpha/Beta/Release (Score:1)
A-L-P-H-A, I know you can say it. (Score:1)
Alpha male? (Score:2)
Alpha, Beta...let's call the whole thing off. (Score:5)
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 [slappy.org].