"If the last RC is stable, it becomes a release without update and for example v1."
About this, some people may not have a 100% complete track and plan to update it in the future, but this still makes it possible to call it v1.0, right?
Now, for those who release it anyway and if the latest version of their track is RC#, how long should it take to change RC# to v1.0, if no glitches are found yet?
e.g. my SNES Donut Plains 1. I made it very fast, but I didn't find any glitches on my own. I still want to give others a chance to find bugs though.
Zilla 01:42, 29 November 2012 (UTC)
- It's best not to use the term RC at all for custom tracks. The RC term comes from software development where a lot of things can go wrong with a program, and therefore the program has to be thoroughly tested. It's often necessary to test several release candidates before a stable build of even a simple program can be released to the public.
- There simply isn't nearly as much that can go wrong with a CT as with a program. A track release release almost always falls under one of two categories: a beta for limited testing that is considered by the author to be incomplete or an actual release that is considered to be reasonably complete. If it's a stable release, and if you want people to consider your track for distributions, then call it V1. If you have to update because of a glitch, your next release will be V1.1 or V1.01. If Otherwise you should call your release a beta. --Jefe 02:05, 29 November 2012 (UTC)
- I have written this page because everyone used things like RC1.1 for a release and also for previews and betas. The article should lead through versioning. Normally, a user needs PREVIEW or ALPHA fpr really incomplete tracks, BETA for playable and V for ready tracks. Nowadays I use RC only for a small distribution for my online tests.
- Wiimm 08:35, 29 November 2012 (UTC)
- That's true, however Alpha/Preview versions are normally not released to the public. They are typically shown as videos.--Jefe 14:23, 29 November 2012 (UTC)