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, taking usage statistics into account. For instance, we currently support four major versions of Visual Studio.
• 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 platforms or platform versions Microsoft or others may come with.

After the release of a version, our support team may refuse to provide support for the use of PostSharp on platforms that:

• have not been patched with all important updates published by Microsoft, or
• are no longer supported by Microsoft even if the specific PostSharp version is still under support and did officially support the platform when it was initially released.

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:

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

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.

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 Virus Total.
3. All developer workstations and build agents are equipped with anti-malware software.