Inferencium/website
1
0
Fork 0
Code Issues Activity

Add section "Versioning" and subsections

Browse Source
This commit is contained in:
inference 2024-01-30 16:12:41 +00:00
parent 598f7b8fbf
commit 9fda4f1f90
Signed by: inference
SSH Key Fingerprint: SHA256:FtEVfx1CmTKMy40VwZvF4k+3TC+QhCWy+EmPRg50Nnc
1 changed files with 95 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
about.xhtml
View File

@ -1,7 +1,7 @@
<!DOCTYPE html>
<!-- Inferencium - Website - About -->
<!-- Version: 8.0.0-alpha.5 -->
<!-- Version: 8.0.0-alpha.6 -->
<!-- Copyright 2022 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
@ -46,6 +46,11 @@
</ul>
<li><a href="#licensing-open_source_vs_free_software">Do I Distinguish Between Open-source and Free Software?</a></li>
</ul>
<li><a href="#versioning">Versioning</a></li>
<ul>
<li><a href="#versioning-numbering_scheme">What is the Numbering Scheme?</a></li>
<li><a href="#versioning-phases">What Are the Phases?</a></li>
</ul>
<li><a href="#services">Services</a></li>
<ul>
<li><a href="#services-websites">Websites</a></li>
@ -179,6 +184,95 @@
push an ideology by a specific group of people. If software
isn't "free", it's not open-source, either.</p>
</section>
<section id="versioning">
<h2><a href="#versioning">Versioning</a></h2>
<section id="versioning-numbering_scheme">
<h3><a href="#versioning-numbering_scheme">What is the Numbering Scheme?</a></h3>
<p>All code uses
<a href="https://semver.org">Semantic Versioning</a>.
The numbering scheme divided into 3 blocks (herein referred to
as Block 0, Block 1, and Block 2, in left-to-right order); the
version blocks are separated by periods. When a version number
block is incremented, all blocks to the right of it are reset to
0. The legacy versioning scheme was a similar numerical
versioning scheme which lacked standardisation.</p>
<p>Block 0 contains the <code><var>MAJOR</var></code> version;
this number is incremented whenever an API-incompatible change
is made to the code.</p>
<p>Block 1 contains the <code><var>MINOR</var></code> version;
this number is incremented whenever an API-compatible,
substantial change is made to the code, such as adding a
feature.</p>
<p>Block 2 contains the <code><var>PATCH</var></code> version;
this number is incremented whenever an API-compatible,
unsubstantial change is made to the code, such as fixing or
optimising the code.</p>
<p>Development and pre-release versions are suffixed with
a hyphen, followed by their phase, a period, then the version of
that phase; for example, <code>-alpha.<var>n</var></code> for an
alpha version, <code>-beta.<var>n</var></code> for a beta
version, and <code>-rc.<var>n</var></code> for a release
candidate version, with <code><var>n</var></code> being a
non-negative integer. Stable versions have no suffix.</p>
</section>
<section id="versioning-phases">
<h3><a href="#versioning-phases">What Are the Phases?</a></h3>
<p>There are 4 phases of development. Each phase typically has
its own branch in each source code repository. The phases are as
follows:
<ol>
<li>Alpha: Pre-alpha development and alpha
testing occurs in this phase. Features are
added, modified, and/or removed. Fixes and
optimisations may also occur if they are caught
during this phase. This is where the majority of
changes occur and where the fine-grained commits
can be found. Breakage is highly likely within
this phase as it makes no attempt to be stable
or usable due to being where the most rapid
development occurs. Code is tested internally in
a fine-grained manner and is moved to the next
phase only when it is deemed feature-complete
and reasonably stable for broader public
testing. If you would like to assist in testing
code in this phase, you must use the code and/or
tags from the source code repositories due to it
not being available publicly outside of
them.</li>
<li>Beta: Feature-complete testing occurs in
this phase. Only bug fixes and optimisations
occur in this phase, such as stability and
security fixes. This phase is classified as
stable enough for broad public testing and is
made available publicly in many cases without
having to use the source code repositories.
Since this phase contains only feature-complete
code, no features will be added, modified, or
removed in this phase.</li>
<li>Release candidate (RC): Feature-complete
testing occurs in this phase. Code in the RC
phase is often stable enough for production
usage, but is not yet completely acceptable to
be classified as stable by my standards. This
phase is often skipped due to most bugs being
caught in the beta phase, but will be used
should the need arise for finer-grained testing
beyond what the beta phase can provide. Like the
beta phase, code in this phase is available
publicly without requiring usage of the source
code repositories.</li>
<li>Stable: Feature-complete and well-tested
code is moved to this phase. Code in this phase
is deemed to be stable enough for production
usage and full support is provided.</li>
</ol>
</p>
<p>When development of a new version has begun, the code within
the alpha phase is rebased onto the most recent code from the
stable phase before work commences. This cycle continues for the
lifetime of the code.</p>
</section>
</section>
<section id="services">
<h2><a href="#services">Services</a></h2>
<p>This list contains the policies and practices of my services.</p>