Inferencium/website
1
0
Fork 0
Code Issues Activity

Fix ordered and unordered lists

Browse Source 
Lists are standalone tags, not placed within paragraph tags. Also, fix
code indentation due to this change.
This commit is contained in:
inference 2024-02-15 06:36:56 +00:00
parent 078ac5e5ac
commit 30c5be1f17
Signed by: inference
SSH Key Fingerprint: SHA256:FtEVfx1CmTKMy40VwZvF4k+3TC+QhCWy+EmPRg50Nnc
1 changed files with 50 additions and 61 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

111
about.xhtml
View File

@ -1,7 +1,7 @@
<!DOCTYPE html>
<!-- Inferencium - Website - About -->
<!-- Version: 8.1.0 -->
<!-- Version: 8.2.0-alpha.1 -->
<!-- Copyright 2022 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
@ -350,54 +350,46 @@
<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>
follows:</p>
<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>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
@ -767,18 +759,15 @@
to protect user keys using the device's hardware
security module.</p>
<p>Molly is available in
<a href="https://github.com/mollyim/mollyim-android#free-and-open-source">2 flavours</a>:
<ul>
<li>Molly, which includes the
same proprietary Google code as
Signal to support more
features.</li>
<li>Molly-FOSS, which removes
the proprietary Google code to
provide an entirely open-source
client.</li>
</ul>
</p>
<a href="https://github.com/mollyim/mollyim-android#free-and-open-source">2 flavours</a>:</p>
<ul>
<li>Molly, which includes the same
proprietary Google code as Signal to
support more features.</li>
<li>Molly-FOSS, which removes the
proprietary Google code to provide an
entirely open-source client.</li>
</ul>
</td>
<td headers="software-smartphone-source_model molly">
Open-source<br/>