Developing in the long run

Support Policies

This page explains our current support policies. Note that nothing in these policies is legally binding. We may change support policies without notice and we may decide to make exceptions to these policies.

Backward Compatibility

In general, we try not to break backward compatibility until there is a compelling reason for doing it. However, when we do break backward compatibility, we do it at a change of major release.

That is, we do not break backward compatibility with bug fix releases or minor releases. For instance, 4.1 is compatible with 4.0 but 4.0 breaks from 3.1.

Release Life Cycle

We maintain two major versions: the current one and the previous one. In each major version, we only maintain the latest minor version.

Supported Platforms and Frameworks

When we release a new major version, we remove support for platforms, frameworks, compilers and other tools that are no longer in mainstream support from Microsoft or their vendor. We may also remove support if we think there are too many supported versions of the platform currently supported. For instance, we currently support three major versions of Visual Studio in each of our major versions. Support of these retired platforms would be continued only in the previous major version. Customers of these retired platforms may still use a supported version of PostSharp during some time but may not upgrade to a new major version.

We reserve the right not to implement support for all new platform or platform version Microsoft or others may come with.

Support Level for Commercial Customers

Support Tickets

We generally answer 4 business hours to any message – whether it is an initial question or a clarification. Due to the complexity of the product, we do not employ support engineers. You will be directly in contact with the software engineers who built the product.

Note that we generally don't debug your source code neither offer support through screen sharing.

Bug Fixing

At PostSharp we are on a 3-week iteration pace. Normally, each iteration, we release one build per maintained branch (which means generally 3 branches: the current stable branch, the previous major version and the in-development branch if it is already ready for preview).

We use 5 priorities of bug fixes:

Priority Description
ASAP Fix and publish the fix as soon as possible (cycle time: typically 1 or 2 business days).
Current Iteration Fix during the current iteration and include in the planned build (cycle time: up to 3 weeks).
Next Iteration Fix during the next iteration and include in the planned build (cycle time: up to 6 weeks).
Later Fix in a special bug-fixing iteration or in a later release.
Maybe No guarantee that the bug will ever be fixed.

We are assigning priorities to bug fixes according to the following rules:

Severity Description Priority
Low It does not work according to design and a workaround exists or the defect in a release that is older than 18 months. Later
Normal It does not work and there is no workaround and the use case has never worked. Next Iteration
High It does not work and there is no workaround and the use case worked in a previous build. Current Iteration
Critical Severals developers cannot do their normal work because of our product and there is no workaround, not even rolling back to a previous build. ASAP

Note that commercial customers escalate the priority of issues that have been reported by non-commercial users.

Support Level for Non-Commercial Customers

We provide strictly no support to non-commercial users of PostSharp. We will consider fixing bugs reported by non-commercial users only if they submit a complete reproduction and if it is obvious that it is a bug. We suggest non-commercial users to seek support on StackOverflow and tag this question with postsharp.

Online Chat

We provide online chat for technical questions. Our objective is to provide instant answers to small questions. For questions that require research or diagnostic, please use other support channels.

Quality Standards for Release Candidates

At PostSharp, we take the term release candidate seriously, which means that RC should have the same quality as an RTM, with the difference that it has been less tested by customers.

Before we tag a new release as RC quality, the following criteria must be fulfilled for all features:

  1. Features are fully implemented.
  2. Features are reasonably tested, including error conditions.
  3. Features are documented, both with conceptual and procedural documentation.
  4. Features have been tested on physical devices.
  5. All public APIs have gone through extensive critical review.
  6. All bugs with higher priority than Later have been fixed.
  7. FxCop warnings have been addressed for public APIs.
  8. Integration with new features and old features has been tested.

Security Standards

We have implemented the following security practices:

  1. Our executables and libraries are signed with Authenticode.
  2. We scan all deliverables with more than 40 anti-malware engines thanks to Metascan Online.
  3. All developer workstations and build agents are equipped with anti-malware software.

Related Pages

See also our Product Roadmap.