Aidan C. Mullen
d460a7ca93
Add portable filesize and logging C libraries and documentation for development.
90 lines
2.9 KiB
Text
Executable file
90 lines
2.9 KiB
Text
Executable file
2.1 VERSIONING
|
|
==============
|
|
|
|
The version-scheme used to track progress.
|
|
|
|
I. Basic Structure
|
|
------------------
|
|
|
|
u.v.w-x.y
|
|
|
|
Major Version
|
|
|
|
The first number, "u" in the example, represents the current major
|
|
version. A major version of "0" means that the software is not fully
|
|
complete; it's only incremented when backwards compatibility is lost.
|
|
|
|
Minor Version
|
|
|
|
Minor versions utilize the second number, "v" in the example,
|
|
and are incremented when new features are added.
|
|
|
|
Patch
|
|
|
|
Patches, "w" in the example, are generally small releases that only
|
|
fix bugs and make small improvements to the existing feature-set.
|
|
|
|
Pre-Releases
|
|
|
|
Preleases fill-in the "x" and "y" in the example. These indicate
|
|
that the release is either an alpha or a beta, meaning that it is
|
|
unfinished or not fully tested. To continue, the suffix (x), will be
|
|
replaced with an "a" for alpha releases, a "b" for betas, and an "rc"
|
|
for release candidates. To iterate, the "y" is substituted with a
|
|
number that is incremented with each passing alpha or beta release.
|
|
Please note that the "-x.y" extension is only added for pre-releases,
|
|
and is absent in stable versions.
|
|
|
|
Full Example
|
|
|
|
1.3.7-b.4
|
|
|
|
Represents the fourth beta of the seventh patch for the third
|
|
minor version of the first major release.
|
|
|
|
II. Branches
|
|
------------
|
|
|
|
This software utilizes branches in order to organize new features and
|
|
remove bugs as they move down the "pipeline" or "stream".
|
|
|
|
Pre-Alpha
|
|
|
|
All new features begin within their own Git branches. This allows
|
|
them to be contained and prevent breakage caused by other features. Once
|
|
an extremely early version of the feature is complete, it is moved into
|
|
the "Alpha" branch.
|
|
|
|
Alpha
|
|
|
|
During the "Alpha" stage, features will most likely be buggy and
|
|
more prone to problems; the goal of alphas in this project is to fix any
|
|
critical bugs and complete the feature. During this phase, features
|
|
are merged into a staging branch that will eventually become the future
|
|
"stable" branch.
|
|
|
|
Formatting: x.y.z-a.x
|
|
|
|
Beta
|
|
|
|
The "Beta" stage comes once a feature is complete, but still needs
|
|
further testing. The "freeze" applied to further development of the
|
|
feature prevents excess bugs from appearing.
|
|
|
|
Formatting: x.y.z-b.x
|
|
|
|
Release Candidate
|
|
|
|
By this stage, critical issues have been resolved, leaving only
|
|
final testing to be done.
|
|
|
|
Patches begin here, as they do not require a full alpha or beta build.
|
|
|
|
Formatting: x.y.z-rc.x
|
|
|
|
Stable
|
|
|
|
"Stable" is the end-user release and is based on the branch of the
|
|
same name.
|
|
|
|
--- end of 2.1 VERSIONING ---
|