Wetware Server Bug Fix Policy

Effective starting: March 28, 2019

•    Our Support team will help with workarounds and bug reporting
•    We'll generally fix critical bugs in the next maintenance release
•    We schedule non-critical bugs according to a variety of considerations

Bug reports
Wetware Support is enthusiastic and happy to help verify bugs - we pride ourselves on that! Create an issue in our support system, providing as much information on how to replicate the problem you're experiencing. If we can’t replicate the problem, we have a harder task to fix it.  We will replicate the bug for verification, then lodge the report for you. We'll also try to provide workarounds if possible.

Search existing bug reports
Use our public issue tracker to search for existing reports, add your report, and watch issues that are important to you. When you watch an issue, we'll send you an e-mail notification when the issue's updated.

How we approach fixing bugs
Bug fix releases are more frequent than feature releases and target the most critical bugs affecting customers. The notation for a bug fix release is the final number in the version (the 1 in 2.0.1, for example).

We assess each bug based on the symptom severity (e.g. when this bug is observed, how severe is what is observed). There are three levels of symptom severity.

Severity 1 - Critical
Your application is unavailable. Users are not able to perform their job function, and no workarounds are available. 

Severity 2 - Major
A feature is unavailable, application performance is significantly degraded, or users job functions are impaired. 

Severity 3 - Minor
The application or specific feature isn't working as expected, but there is a workaround available. Users experience is impacted, but their job function is not impaired.  

Assessing bugs using symptom severity makes sure that we prioritise the most beneficial fixes. We give high priority to security issues.

Workflow terminology

To make understanding our bug fix policy easier, here's some definitions.

•    Needs triage: This issue is waiting to be reviewed by a member of the Wetware product team. Usually only recently created issues are in this status. Our product teams review these issues regularly.

•    Gathering impact: This issue has been reviewed but needs further substantiation to gauge how pervasive the problem is.

•    Long term backlog: A fix for this issue is required but planned for farther in the future. This is because it’s not as severe or pervasive as other issues needing attention.

•    Short term backlog: A fix for this issue is required and will be prioritised as soon as practicable. This is because it’s more severe or pervasive than other issues needing attention.

•    In progress: The development team is working on this issue at present.

•    In review: A fix for this issue has been proposed and is being reviewed and quality-tested by the development team.

About our bug fix workflow
If you identify a bug as affecting your team, it’s useful to understand how we review, prioritise, and resolve them in our public issue tracker.

We prioritise issues using a metric called User Impact Score (UIS), which is individually calculated for every issue.  It factors in the number of affected users, issue severity, recent interest, and the percentage of users affected per instance. The higher the UIS score, the higher priority the issue is.

We have a standardised workflow (and statuses) across Server and Data Centre products to make it easy for you to see where an issue is at.  Here’s our workflow and a description of each status.

How to get access to bug fixes
To get access to bug fixes you will need to upgrade to a release that contains the fix.

Release terminology
To make understanding our bug fix policy easier, here's some definitions.

•    Platform release (2.0) contains significant or breaking changes. E.g.: changes or removal of existing APIs, significant changes to the user experience, or removal of a major feature.
•    Feature release (2.6) can contain new features, changes to existing features, changes to supported platforms (such as databases, export formats), or removal of features. 
•    Bug fix release (2.6.2) can contain bug fixes, stability and performance improvements. Depending on the nature of the bug fixes they may introduce minor changes to existing features, but do not include new features or high-risk changes, so can be adopted quickly. We recommend regularly upgrading to the latest bug fix release for your current version. 

In addition to the three main release types, a feature release can also be designated an Enterprise release, which means it will receive bug fixes for a longer period of time than a standard feature release.

Enterprise releases
Enterprise releases are for Server and Data Centre customers who prefer to allow more time to prepare for upgrades to new feature versions, but still need to receive critical bug fixes. If you only upgrade to a new feature version about once a year, an Enterprise release may be a good fit for your organisation. For Projcycle Software we will:

•    Designate a feature release as an Enterprise release, at least every 12 months.
•    Backport critical security fixes, as outlined in our current security bug fix policy, and fixes relating to stability, data integrity or critical performance issues.
•    Make bug fix releases available for the designated version until it reaches end of life. 
•    Provide a change log of all changes between one Enterprise release and the next to make upgrading easier.


Not all bug fixes will be backported. We'll target the bugs and regressions that we deem most critical, focusing on stability, data integrity, or performance issues. There may also be some fixes that we choose not to backport due to risk, complexity or because the fix requires changes to an API, code used by third party apps, or infrastructure that we would usually reserve for a platform release.