Version Release Policy Printable Version

This document serves to set forth, in writing, the VaultWiki Team internal policy for scheduling updates to the VaultWiki software.

When responding to support inquiries, an employee may declare that a given issue is resolved using language like "in the next" "build", "release", "patch", or other such term. This document also serves to set forth the differences between these to help customers understand when a change should be expected to be included.

Security Patches

As described in the License Agreement (sec 8.1), a Security Patch, often called a "Patch", is reserved for specific classes of software bugs:

• Security vulnerabilities, including those involving: Remote Code Execution, Local File Inclusion, MySQL Injection, Denial of Service, Denial of Service Amplification, Permissions Escalation, HTML Injection, Javascript Injection, Phishing, or Information Disclosure;
  
• Data vulnerabilities, including those involving: unintentional Data Loss, or Expired Pointer Dereference;
  
• Serious User Experience issues, including those involving: Subscription Management, or On-Site Alerts;
  
• Legal issues, including those involving: GDPR, or Copyright;
  
• Other Serious issues, such as hung upgrade processes.

If such an issue was reported by a user, typically an employee will reply using language such as "escalated to security", and may elect not to post manual patching instructions and/or close the report to public access, if there is potential for actors to use the information maliciously.

Security Patches are generally published during the first 10 days of a calendar month, provided that a qualifying issue was confirmed by VaultWiki Team within 30 days preceding such date. If the Security Patch would include an especially serious issue, and that issue is known to be exploited in the wild, VaultWiki Team may elect to publish a Security Patch sooner, but no fewer than 48 hours since the last applicable Minor Point Version Release, Build, or Security Patch.

Patches shall be published for all vulnerable versions originally released within 365 days prior to the patch's release date, except where the version is already EOL or is an Alpha, Beta, or Release Candidate (RC) release. The processes for notifying customers of a new Security Patch are further discussed in the License Agreement (sec 8.1). VaultWiki Team may additionally elect to publish a Security Patch for a version originally released before 365 prior to the release date, as long as at least 1 issue resolved by the Patch was confirmed within 365 days after that version's release date, at their discretion.

Minor Point Version Releases

New versions of VaultWiki are denoted with a version number like x.x.1, x.x.2, etc, and are typically referred to by employees as a "release" or a "version". These Releases do not have any specific ETA. Instead every new version has a specific Release Threshold that must be met before beginning the process of making a release public:

• At least 21 days after the previous version release; AND
  
• At least 10 changes in the changelog, or at least 60 days after the previous version release; AND
  
• Fewer than 5 active bug reports on the web site, not counting: duplicates, cannot reproduce, or flagged for future; AND
  
• No more than 0 active critical bug reports on the web site, including any that may be escalated to be addressed by Security Patch, and including any involving: installation or upgrade issues, permissions de-escalations, non-functional major software components, or moderate user experience issues in major software components; AND
  
• Any additional bugs that were found internally by employees, regardless of severity, must be resolved or flagged for future.

If all of the above are satisfied, then the Release Process may be initiated. If at any point during the Release Process, the Release Threshold is no longer satisfied, the Release Threshold must be satisfied again before continuing the Release Process.

The Release Process proceeds as follows, while the Release Threshold is actively satisfied:

1. New version notes, including changelogs and style change info, must be compiled and posted to the documentation on the Web Site; AND
   
2. The upgrade scripts are tested in place on vBulletin 4, XenForo 1.x, and XenForo 2.x. If the release contains non-trivial changes to the installer, additionally the install scripts are tested in place on vBulletin 4 and XenForo 2.x; AND
   
3. VaultWiki Team prepares and compiles packaging data for the packager, which uses that data to automatically generate a ZIP file containing a non-development, sample copy of the Software and its component files; AND
   
4. VaultWiki Team uses the sample package to upgrade standalone installations on vBulletin 4, XenForo 1.x, and XenForo 2.x; AND
   
5. Wait 3 days; AND
   
6. Release the package to customers, and post an announcement about the release.

Minor Point Builds

New builds of VaultWiki, typically referred to by employees as a "build", do not have any specific ETA. Builds do not change the version number or require the customer to run the upgrade script, and are generally unannounced. Customers can learn about new builds by checking the "Last Product Update" indicator on the Web Site's forums list, or by checking the Software Update indicator in their installation's administration panels.

Builds are issued for the most recently published Minor Point Version Release only, unless that release has already received a Security Patch, and are issued to address:

• Critical bugs, typically involving: installation or upgrade issues, permissions de-escalations, non-functional major software components, or moderate user experience issues in major software components; AND
  
• If the Release addressed by the Build falls outside of the patchable versions listed in the License Agreement (sec 8.1), issues that may otherwise be addressed by Security Patch.

The general timetable for publishing a new Build relies on the discretion of employees after evaluating new support inquiries and internal discoveries, but typically uses the following timetable:

• No fewer than 48 hours since the Minor Point Version Release or prior Build; AND
  
• No more than 14 days since the Minor Point Version Release or prior Build.

In the event that an especially critical issue would normally necessitate a new Build and 48 hours is determined too long of a waiting period, VaultWiki Team may elect to repackage the current Build with the changes included. In this event, employees should notify any customer who reports the issue to re-download and re-apply the same build.

In the event that an especially critical issue would normally necessitate a new Build but the release has already received a Security Patch, VaultWiki Team may elect to include the changes in the next Security Patch even though the issue may not usually rise to the level of Security Patch inclusion. In such event, but if the next Security Patch is determined too long of a waiting period, VaultWiki Team may elect to repackage the current Security Patch with the changes included, and employees should notify any customer who reports the issue to re-download and re-apply the same Security Patch.

First and Second Point Version Releases

New major-point versions of VaultWiki are denoted with a version number like x.1.x, x.2.x, etc, and are typically referred to by employees as a "branch". These Releases do not have any specific ETA. VaultWiki Team assigns one or more themes, or development focuses, to a branch. Thereafter, VaultWiki Team slates any number of features or behavioral changes that largely align with those themes as intended to be included within that branch. However, themes may be added or removed at any time until the branch is published.

The branch shall not be published until:

• Development has entered final stages on all features or changes that can reasonably be disabled until a later pre-stable Release within the same branch; AND
  
• Development has otherwise completed on all features or changes in all currently assigned themes; AND
  
• Changes made to the currently published version are included in the new Branch to the extent that the Branch achieves, at the least, behavioral parity with currently published versions, except where that behavior was slated to change, and includes no reversions regarding patches, bugs already resolved, or minor features added in the currently published version; AND
  
• Any additional bugs that were found internally by employees, regardless of severity, must be resolved or flagged for future.

When publishing a new Branch, the policy regarding Unstable Releases shall be followed, with the earliest published Version under the new Branch starting no later than Beta status.

Individual features may be completed or re-slated to a different branch at any point during the Unstable statuses.

Unstable Version Releases

Whenever a new Branch is published, new Versions shall not be released, whether with or without special designation, when the presence or lack thereof of such designation may lead the public to believe the Branch is Stable, without first proceeding through a period of public scrutiny, where the Versions are classified as follows:

Alpha Status

If there is low confidence in the stability of more than 50% of the changes introduced by the Branch, new Versions in that Branch shall be classified as Alpha. Regardless of the rate at which confidence increases, there shall be at least 3 Versions bearing Alpha status.

Instead every new Alpha version has a specific Release Threshold that must be met before beginning the process of making the Alpha public:

• At least 14 days after the previous version release; AND
  
• Fewer than 15 active bug reports on the web site, not counting: duplicates, cannot reproduce, or flagged for future; AND
  
• No more than 5 active critical bug reports on the web site, including any that may be escalated to be addressed by Security Patch, and including any involving: installation or upgrade issues, permissions de-escalations, non-functional major software components, or moderate user experience issues in major software components; AND
  
• No more than 10 additional bugs that were found internally by employees, regardless of severity, are currently unresolved and not flagged for future.

If all of the above are satisfied, then the Release Process set forth in the section regarding Minor Point Version Releases may be initiated. If at any point during the Release Process, this Release Threshold is no longer satisfied, the Release Threshold must be satisfied again before continuing the Release Process.

Beta Status

If there is low confidence in the stability of more than 30% of the changes introduced by the Branch, new Versions in that Branch shall be classified as Beta. Regardless of the rate at which confidence increases, Beta status shall not be bypassed if the Branch was published during Alpha status, and there shall be at least 3 Versions bearing Beta status.

Every new Beta version has a specific Release Threshold that must be met before beginning the process of making the Beta public:

• At least 21 days after the previous version release; AND
  
• Fewer than 10 active bug reports on the web site, not counting: duplicates, cannot reproduce, or flagged for future; AND
  
• No more than 0 active critical bug reports on the web site, including any that may be escalated to be addressed by Security Patch, and including any involving: installation or upgrade issues, permissions de-escalations, non-functional major software components, or moderate user experience issues in major software components; AND
  
• No more than 5 additional bugs that were found internally by employees, regardless of severity, are currently unresolved and not flagged for future

If all of the above are satisfied, then the Release Process set forth in the section regarding Minor Point Version Releases may be initiated. If at any point during the Release Process, this Release Threshold is no longer satisfied, the Release Threshold must be satisfied again before continuing the Release Process.

Gamma Status

If there is moderate confidence in the stability of more than 50% of the changes introduced by the Branch, new Versions in that Branch may be classified as Gamma. Gamma status may be bypassed if confidence has increased sufficiently during Beta status; however, if Gamma status is used for any published Version, then regardless of the rate at which confidence increases, there shall be at least 3 Versions bearing Gamma status.

Every new Gamma version has a specific Release Threshold that must be met before beginning the process of making the Beta public:

• At least 21 days after the previous version release; AND
  
• Fewer than 10 active bug reports on the web site, not counting: duplicates, cannot reproduce, or flagged for future; AND
  
• No more than 0 active critical bug reports on the web site, including any that may be escalated to be addressed by Security Patch, and including any involving: installation or upgrade issues, permissions de-escalations, non-functional major software components, or moderate user experience issues in major software components; AND
  
• Any additional bugs that were found internally by employees, regardless of severity, must be resolved or flagged for future.

If all of the above are satisfied, then the Release Process set forth in the section regarding Minor Point Version Releases may be initiated. If at any point during the Release Process, this Release Threshold is no longer satisfied, the Release Threshold must be satisfied again before continuing the Release Process.

Release Candidate Status

If there is moderate confidence in the stability of more than 70% of the changes introduced by the Branch, new Versions in that Branch may be classified as Release Candidate, or RC. Regardless of the rate at which confidence increases, Release Candidate status shall not be bypassed, and there shall be at least 3 Versions bearing Release Candidate status.

Every new Release Candidate version has a specific Release Threshold that must be met before beginning the process of making the Release Candidate public:

• At least 21 days after the previous version release; AND
  
• Fewer than 5 active bug reports on the web site, not counting: duplicates, cannot reproduce, or flagged for future; AND
  
• No more than 0 active critical bug reports on the web site, including any that may be escalated to be addressed by Security Patch, and including any involving: installation or upgrade issues, permissions de-escalations, non-functional major software components, or moderate user experience issues in major software components; AND
  
• Any additional bugs that were found internally by employees, regardless of severity, must be resolved or flagged for future.

If all of the above are satisfied, then the Release Process set forth in the section regarding Minor Point Version Releases may be initiated. If at any point during the Release Process, this Release Threshold is no longer satisfied, the Release Threshold must be satisfied again before continuing the Release Process.

Stable Status

If there is high confidence in the stability of more than 90% of the changes introduced by the Branch, and 0 features still slated to be included in the Branch are currently disabled, new Versions in that Branch may, at the discretion of VaultWiki Team, no longer be classified as Alpha, Beta, Gamma, or Release Candidate status. A Branch version newly achieving Stable status shall follow the Release Threshold and Release Process set forth in the section regarding Minor Point Version Releases.