See also Requirements and Compatibility in the reference documentation.
PostSharp distinguishes between major releases, minor releases, and patch releases:
This policy is compatible with the semantic versioning specification.
We use 4 maturity levels:
A project can have references (direct and indirect) to several PostSharp packages of different versions within the same major version. The version of the PostSharp package must be higher than or equal to the version of any other package of the PostSharp family.
Side-by-side compatibility is provided on a "economically reasonable effort" basis. We perform structural tests of backward compatibility (comparison of public APIs, shared internals, and serialization details), but not behavioral tests such as unit tests.
Our support team may ask customers to upgrade all their packages to the same patch release, as there may be no other economically reasonable solution to some issues.
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:
Customers can choose to use the Long Term Support (LTS) releases, Current or Preview releases:
Customers using LTS will need the latest patch update within the same minor release installed to qualify for support.
|Version||Release Date||Support Level||End of Support||Exclusions|
|PostSharp 6.2||May 13, 2019||Current|
|PostSharp 6.1||March 11, 2019||Unsupported||July 13, 2019|
|PostSharp 6.0||July 9, 2018||Unsupported||May 12, 2019|
|PostSharp 4.3||July 27, 2016||LTS||July 28, 2021 or 1 year after some future version is promoted LTS||Xamarin|
In this section, we use the term platform to refer to Windows, .NET Framework, .NET Core or Visual Studio.
This section covers only policies. For a list of supported platforms, please see Requirements and Compatibility in the documentation of each PostSharp version.
By supported (or officially supported) platform version we mean that we have spent or will spend commercially-reasonable efforts to:
It frequently happens, in practice, that PostSharp will work with a non-supported platform version. However, if some issue happens, we will first ask you to upgrade or downgrade to a supported platform version.
Our list of supported versions includes future versions. Of course, it is as impossible to test a product against a future version. Sometimes a new platform version introduces a breaking change that PostSharp cannot cope with without introducing another breaking change.
Therefore, we have no way to guarantee that the current version of PostSharp will support any future version of a supported platform. Consequently, the list of supported platforms of expresses intents, not guarantees. Additionally, a platform version that used to be supported with a PostSharp version was released may no longer be supported by the moment you will file a support request.
If you believe this is a mess, we agree! To mitigate this, consider the strategy of using only Long-Term Support (LTS) versions of platforms and development tools where possible.
Only platform versions that are currently supported by their manufacturer are supported by PostSharp. If the manufacturer differentiates Mainstream Support for Extended Support, only platforms under Mainstream Support will be supported by PostSharp.
Check the support policies of the platform you rely on. The support lifecycle is probably shorter than you would expect! Check the following documents:
Pre-release platform versions are never officially supported, even when they get a production license from their publisher.
Only the latest Patch Release of a supported platform version is officially supported.
Operating systems must be updated with all Important Updates to qualify for support.
Before providing support services to you (such as diagnosing or fixing a bug), we ask you to update PostSharp and all platforms to the latest Patch Release.
When we release a new major or minor release, 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 for a version of a platform if we consider that too many versions of the platform would be otherwise supported, taking usage statistics into account.
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.
We generally answer within 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||Several 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