You're not the only one to make that mistake, and I really think it's down to the fact that gamers, and non-programmers in general, are usually only exposed to beta, maybe RC, and then release (some packages skip RC in favour of post-release patching). So here's a quick précis:BlueX said:i thought beta was used before alpha so i can change the name eq otherwise it may look bad and everything i know i still have stuff to learn but atleast play it before you start breakin it down (in a good way i mean). its different ingame imo.
ALPHA: Just started work or still in progress. There will be bugs/holes/incomplete features/performance problems etc. I just don't know what they all are yet so bug-reports are welcome and should be noted and added to to-fix/to-do list. Also used to designate something which is maybe a prototype or rough version to see if an idea is viable.
BETA: All the functionality/features are complete and hopefully a good reflection of how they will be in the release (unless bug-fixes dictate otherwise). Has been subjected to alpha testing (normally by a very small group of objective individuals, but sometimes by a larger group) and the obvious/large bugs have been fixed, now ready for more widespread testing. This is the normal point for an initial release, and the origin of the misconception that "beta" is the first version of something. "Beta" stuff expects feedback and more minor bug-reports, expect to have to tread carefully so that bug-fixes at this stage don't break things you've fixed before.
RELEASE CANDIDATE (RC): All the stuff learned from the beta stage has been fixed. This would either be a generally available release, or an internal designation meaning "We think it's ready, let's try to prove ourselves wrong". Minor bug-fixes *may* still be required, but we're pretty sure this is it.
RELEASE: The final version. Note that some authors will skip RC-level testing and go straight here, in favour of post-release patching (ie. the "version 2" stuff). For a good reference to this approach see the AlienPod map pack.
How you choose to version stuff is up to you. For maps I have always used the postfixes "ALPHA-1a", incrementing the letter for every internal version, and the number for every test-level version (internal), then used the same system for beta, starting at "BETA-1a".
A good habit to get into is every time you make a significant number of changes to your level, increment the minor version (the letter in this case), and carry on. That way, if you break stuff you always have versions to fall back on. This is especially true when working with complex BSP or with particle systems.
Hope this helps you some.
Last edited: