Difference between revisions of "Version Number"

Revision as of 21:01, 5 October 2018

Introduction

Basic Versioning

Software development goes through several stages and many builds (compiled/generated versions). Sometimes the author wants to publish some of these builds, so the author should find a good version name.

The stages are not clearly defined and the following are only suggestions:

Preview is a very early stage of the software and not usable.
Alpha version is principally complete with known major bugs.
Beta version is nearly ready with known minor bugs.
Release Candidate (RC) has no known bugs.
Release should be bug free.

Preview

A Preview is a very early and incomplete copy of the software. It should give some impressions.

Examples for naming

pre-3
preview4
v3.pre5

Alpha

An Alpha has (nearly) all things implemented and is much closer to a product than a Preview, but it has some known major bugs or some missing parts of the software.

Examples for naming

alpha
a4
v3.alpha-5

Beta

A Beta is nearly ready, has some known minor bugs, and works generally as expected. The author gives it away for tests to find more bugs.

Examples for naming

beta
b4
v3.beta-5

Release Candidate

A Release Candidate (RC) is a candidate for release. The author means that it is bug-free (if not, the author must declare the known minor bugs) and gives it away for final tests. Release candidates may stay as release candidates for extended periods of development during which bugs are repeatedly found and fixed.

Examples for naming

RC1
rc-2
v3.rc2

Release

If the release candidate is stable and well-tested, the next version following it may become a Release and it is renamed to v* where * may be nearly anything.

Examples for naming

v1
v1.2
v1a
v1.12b
v00001.02.0003

The preceding v is often omitted for final releases, where the author has no initial intention of updating the software.

More Specific Version Numbers

Version numbers can be combined with preview, alpha, beta or release candidate (for example, a beta for version 2). Separate the suffix from the main version number by a period.

Examples for naming

v3.pre-1
v12.alpha
v2.b3 (b for beta)
v5.RC3

Proof of concept

A Proof of concept (PoC) is a software version to test a concept of anything, like the »Train for Kalimari PoC«. The goal of a PoC track is not to have a running track, but to find out if a technical detail will work.

Examples for naming

PoC-1
poc2

@@ Line 1: / Line 1: @@
-This article should help to find a correct version number for a software product. A custom track is a software product and should follow the rules, so that all people know what the author mean. The goal is to avoid the RC mixture used by the ct authors.
+== Introduction ==
+{{about|Related article: [http://en.wikipedia.org/wiki/Software_versioning Software versioning]}}
-If an end user gets for example a release candidate (RC), he think he gets a nearly 100% working track and he doesn't expect a buggy alpha with known freezes.
-__TOC__
+This article should help custom track creators find a correct version number for their files. Files listed on the Wiiki are treated as software and should have proper software versioning. The purpose of software versioning is to help the creators stay organized.
 == Basic Versioning ==
+Software development goes through several stages and many builds (compiled/generated versions). Sometimes the author wants to publish some of these builds, so the author should find a good version name.
-If software (and also tracks) is developed it goes through several stages and many builds (compiled/generated versions). Sometimes the author want to publish some of these builds and to find a good version naming.
+The stages are not clearly defined and the following are only suggestions:
+* '''Preview''' is a very early stage of the software and not usable.
-The stages are not clearly defined and the following is only a suggestion.
+* '''Alpha''' version is principally complete with known major bugs.
-A '''preview''' is a very early stage of the software and not usable.
+* '''Beta''' version is nearly ready with known minor bugs.
-An '''alpha''' version is principal complete with known major bugs.
+* '''Release Candidate''' (RC) has no known bugs.
-A '''beta''' version is nearly ready with known minor bugs.
+* '''Release''' should be bug free.
-A '''release candidate''' has no known bugs and is published for final tests.
-A '''release''' is bug free &mdash; or should be bug free.
 === Preview ===
+A Preview is a very early and incomplete copy of the software. It should give some impressions.
-A preview (pre release) is a very early and incomplete copy of the software. It should give some impressions.
 ;Examples for naming:
@@ Line 28: / Line 23: @@
 === Alpha ===
+An Alpha has (nearly) all things implemented and is much closer to a product than a Preview, but it has some known major bugs or some missing parts of the software.
-An alpha version has (nearly) all thinks implemented and is much closer to a product than a ''preview''. But it have some known major bugs or some parts of the software are missed.
 ;Examples for naming:
@@ Line 37: / Line 31: @@
 === Beta ===
+A Beta is nearly ready, has some known minor bugs, and works generally as expected. The author gives it away for tests to find more bugs.
-A beta version is nearly ready, has some known minor bugs and works generally as expected. The author(s) give it away for tests to find more bugs.
 ;Examples for naming:
@@ Line 46: / Line 39: @@
 === Release Candidate ===
+A Release Candidate (RC) is a ''candidate for release''. The author means that it is bug-free (if not, the author must declare the known minor bugs) and gives it away for final tests. Release candidates may stay as release candidates for extended periods of development during which bugs are repeatedly found and fixed.
-A release candidate (RC) is a ''candidate for the release''. The author means, it is ready and bug free (if not, he must declare the known minor bugs) and give it away for final tests.
-RC1 means ''first release candidate'' and RC2 ''second release candidate''. Numbers like RC0.9 and RC1.4 are nonsense.
 ;Examples for naming:
@@ Line 57: / Line 47: @@
 === Release ===
+If the release candidate is stable and well-tested, the next version following it may become a Release and it is renamed to v* where * may be nearly anything.
-If the release candidate is stable and well tested, you rename it to "v*". "*" may be nearly anything.
 ;Examples for naming:
@@ Line 66: / Line 55: @@
 * v1.12b
 * v00001.02.0003
-The preceding ''v'' is often omitted.
+''The preceding '''v''' is often omitted for final releases, where the author has no initial intention of updating the software.''
-You can also combine version numbers with preview, alpha, beta or release candidate. You need the if you plan e.g. e beta for version 2. Separate the suffix from the main version number by a dot.
+== More Specific Version Numbers ==
+Version numbers can be combined with preview, alpha, beta or release candidate (for example, a beta for version 2). Separate the suffix from the main version number by a period.
 ;Examples for naming:
@@ Line 76: / Line 66: @@
 * v5.RC3
-== Alternative Versioning ==
+== Proof of concept ==
-=== Proof Of Concept ===
+A Proof of concept (PoC) is a software version to test a concept of anything, like the [http://www.youtube.com/watch?v=z4zaiKSKUqo »Train for Kalimari PoC«]. The goal of a PoC track is not to have a running track, but to find out if a technical detail will work.
-A ''Proof Of Concept'' (short ''POC'') is a software version to test a concept of anything, like the [http://www.youtube.com/watch?v=z4zaiKSKUqo »Train for Kalimari POC«]. The goal of a POC track is not to have a running track, but to find out, if a technical detail will work.
 ;Examples for naming:
-* POC-1
+* PoC-1
 * poc2
 [[Category:General Information]]