Support Policies

In this document

• Disclaimers
• Versioning and Backward Compatibility Policies
• Quality Standards
• Security Standards
• Support Lifecycle Policy
• Supported Platforms and Frameworks
• Support Level for Commercial Customers
• Support Level for Non-Commercial Users

See also Requirements and Compatibility in the reference documentation.

Disclaimers

• Nothing in these policies is legally binding. We work on an "economically reasonable effort" basis.
• We may change policies without notice.
• We may decide to make exceptions to these policies.

Versioning and Backward Compatibility Policies

Versioning

PostSharp distinguishes between major releases, minor releases, and patch releases:

• Major releases are any release which updates the Major version number. For example, 5.0 is updated to 6.0. Major releases may introduce breaking changes both at source code and binary levels.
• Minor releases are any release which updates the Minor version number. For example, 6.0.0 is updated to 6.1.0. Minor releases typically introduce new features that could possibly cause regression bugs. However, there is both a feature freeze and a platform freeze after a minor releases reaches the stable maturity level (as opposed to preview or rc maturities).
• Patch releases are any release which update the Patch number. For example, 6.0.10 is updated to 6.0.11. Patch releases only correct bugs and are therefore unlikely to introduce regressions.

This policy is compatible with the semantic versioning specification.

Maturity

We use 4 maturity levels:

• Alpha releases are private builds, prior to making them public;
• Previews are intermediate public builds that are not yet feature-complete and may still be subject to breaking changes;
• Release Candidates (RC) meet all quality standards for a stable releases, except that they have not been tested in the wild;
• Stable means that all quality standards are met and the feature freeze applies. The moment when a release is marked as stabled is called the general availability date. At this moment, the releases appear in the stable channels in our web site, on Visual Studio Marketplace, and on NuGet Gallery, and it starts to be massively downloaded. Note that it typically takes 4 to 6 weeks after a new Major.Minor release is marked as stable before most bugs surface.

Side-by-Side Versions

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.

Quality Standards

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.

Support Lifecycle Policy

Customers can choose to use the Long Term Support (LTS) releases, Current or Preview releases:

• LTS releases are supported for 5 years after the general availability date or 1 year after a subsequent release has been promoted LTS, whichever is shorter.
  • A Current release will not be promoted LTS sooner than 6 months after its general availability date. Not all releases will be promoted LTS.
  • At the time a Current release is promoted LTS, we may apply Exclusions to the support. Exclusions are features or platforms that are no longer supported in this release and that either require an update to a subsequent release, or have been abandoned. We apply exclusions when it is not economically or technically viable to continue to support these features or platforms in this release.
• Current releases are supported for 2 months after the general availability of another Current release.
• Preview releases (including alpha releases and release candidates) are supported until the next Preview or Current release of the same minor version is published.

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.0	N/A	Preview
PostSharp 5.0	July 10, 2017	Current	2 months after PostSharp 6.0 is released	.NET Standard, .NET Core
PostSharp 4.3	July 27, 2016	LTS	1 year after PostSharp 6.0 is promoted LTS	Xamarin

Supported Platforms and Frameworks

• 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.

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 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.

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.