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.
Please look at Requirements and Compatibility in the reference documentation.
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.
We maintain two major versions: the current one and the previous one. In each major version, we only maintain the latest minor version.
After the release of a version, our support team may refuse to provide support for the use of PostSharp on platforms that:
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.
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:
|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:
|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.
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
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:
We have implemented the following security practices: