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.
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.
|PostSharp 1.0-3.0||Unsupported (deprecated)|
|PostSharp 4.0-4.2||Unsupported (deprecated)|
|PostSharp 5.0||Unsupported (preview)|
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.
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
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.
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:
See also our Product Roadmap.