The advantage of giving people early code is that their feedback can be more easily incorporated into the project. A beta product that’s finished and been through internal testing isn’t that likely to change in a major way if an end user comes up with a good idea or finds a major flaw in the way that it works.
I think IE8 beta 1 is a good example. It’s not that useful for browsing the web but it gave the web development community a chance to give feedback to the IE team at a point in the development cycle when it could still affect the final product.
I actually never heard the term gold for final release. Just to know that it was released or that I/we released was enough.
Remember the joke: The support technician told a customer that they couldn’t help them because the software was in gamma testing release, even though they payed money for it. The joke being that purchased software is just in another testing phase. Makes me feel great as a consumer.
I never knew that gamma was another term for release candidate.
I wonder how the pre-alpha/ alpha/ beta/ RC/ gold release process can
be suitably used in agile software development.
They don’t really fit except as labels for iterations. IMO they don’t actually match reality all that often.
There is only value in having these steps when the release/install process is hard (eg selling commercial software on CD, updating thousands of users at the same time in a commercial environment etc)
@Inder P Singh:
Even in an agile development you will have a kind of alpha/beta/release.
For instance by using Scrum, at the end you will deliver a featured and stable (deliverable) version of an application.
Means during a sprint you will reach a test system. There you will run feature tests and regression tests. After tested ok on test, you will move to a beta environment and do the same testing (beside of that you may have stress tests, too). And after tested ok on beta, you will have a release candidate - even if this does not mean that you will release it, because you need several sprints to inlcude all features.
As some people have pointed out in comments already, the term Release Candidate (aka gamma or delta) is a non-sequitur. Either it is a candidate for release or it isn’t. Betas are never simply re-branded final if they’re found to be bug free (if they can be re-branded without change, they aren’t betas! Betas should be lacking the necessary fluff that wraps a final version, like a spell-checked README, a nice logo, etc), but RC’s are. That’s the difference. The term Release Candidate (aka gamma or delta) makes it sound as if the next letter in the alphabet is simply the next version, which would turn the whole system of release classifications into fuzzy jelly, don’t you think?
So, article writer, here’s hoping you’ll adopt the views of the software community outside Redmond/Mountain View, and stop using the term Release Candidate (aka gamma or delta).
The way I have always heard the terms used is that alpha testing is private and in-company; beta testing involves releasing the product to (some) users outside the company.
Different kinds of product have very different test cycles. For example, console video games typically do not undergo beta testing: members of the public don’t get to see the game until its release. On the other hand, many free software projects have essentially no alpha testing other than that done by the programmers as they work: these projects rely completely on public beta testing.
A gold release is one that is final in some way, or that is expensive to recall, for example a console video game that has gone to manufacture or distribution. Software that users update on a regular basis has no need of gold releases: the developers can always make another version available.
As previous posters have said, Gold referred to the master sent to manufacturing. It was usually magnetic tape before CDs existed. In the enterprise software business, RTM (release to manufacturing) and GA (General Availability) are the most used terms. Of course, now there is almost no manufacturing, so GA is the dominant term. I used to hear Gold primarily at PC software companies in the 90s.
I would differ slightly on the definitions Jeff gave. I think Alpha should mean functionally complete and passes all developer testing and initial QA testing. Beta should mean that it passes enough QA testing to be used more widely. After, alpha, the only changes should be bug fixes. Of course, my definitions don’t fit the web 2.0 mode of continuous changes.
I have heard Gamma used instead of RC, but very infrequently.
Release Candidate (aka gamma or delta): The software is almost ready for final release
I so hate this definition! (although this seems to be the meaning in the industry).
In my book Release Candidate is exactly that: I really, truly believe this is ready for release. All the bugs that I know of are not going to be fixed for the final build. If no new major bug is discovered in this build, then this is the Gold!
So Gold is not a special build, it is putting the official stamp on the last Release Candidate. And the last RC becomes the Gold.
Apparently the CIA actually managed to put a bug in the Soviet natural gas pipeline control software back in the early 80’s that caused an explosion large enough to see from space!
The best part of it is that they didn’t hack anything in Russia; they just slipped the bug into some software they new the Soviets wanted to steal. That way they couldn’t even complain about it.
@Ortzinator Web applications do have release numbers, or at least they should have. Any site developed with even slightly more advanced release planning than directly editing the code on the production server should have some way of distinguishing different versions. However, the version number is often only used for internal purposes and is never communicated to the user. You typically don’t see a changes.txt file on most web sites.
I see a lof of people argue that the alpha and beta labels are useless with the current practice of incremental releases and frequent updates to web sites and software. Personally I think version numbers are better suited for that. For example, you could have version 1.0 alpha, 1.0 beta, 1.0 release candidate and 1.0 (final). When you add new features you go to version 1.1 alpha, 1.1 beta and 1.1 (final), and so on. If you always stay in beta and go directly from 1.0 beta to 1.1 beta, you are basically not completing the full release cycle for each update, possibly resulting in software with more features but lower quality.
I think the alpha, beta and release candidate labels still have some uses, but what they actually mean to a certain team or product may have to be defined specifically for each situation. For example, a team may decide that no new features can be added to the product after beta, or that after release candidate only bugs classified as critical will be fixed. This may or may not have any actual value to the end user.
Websites/Web applications are NEVER done. The release cycles of every Web company I’ve ever worked in had new code updates at least once a week. For a long time at Amazon.co.uk we did code updates to the live site EVERY DAY! Major feature releases might only happen once every month. Oo-ah!
So, the idea of Web2.0 sites being in permanent beta is a bit silly, I think. Once you get over the initial hump of actually having a functioning application with a releasable (and usable) set of features that you can let the public play with (as opposed to just a select group of people) then you are no longer in beta. You are in production.
The worst thing about the permanent beta is that it lets programmers and managers at some companies think that they can let lesser quality code out onto their production servers because they think that it’s just beta, and people know that. No. BS. People are USING YOUR SOFTWARE. Have a little self respect and respect for your customers. Give them software that’s been properly tested in house and/or amongst a small group of hard-core beta testers (on a separate server) before you push those changes to live.
