Support Policies

In this document

See also Requirements and Compatibility in the reference documentation.


  • 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


PostSharp follows the versioning scheme YYYY.N.B[M], where:

  • YYYY is the current or next year,
  • N is the version number within this year,
  • B is the build number within the minor version,
  • M is the release maturity level (see bellow),

We make no difference between a major and a minor version. We distinguish only versions (YYYY.N) and builds (B).


We use 4 maturity levels:

  • -alpha releases are private builds, prior to making them public;
  • -preview releases are intermediate public builds that are not yet feature-complete and may still be subject to breaking changes;
  • -rc releases meet all quality standards for a stable releases, except that they have not been tested in the wild;
  • Stable (Generally Available/GA) releases meet all quality standards and the feature freeze applies. The moment when a release is marked as stable 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 YYYY.N version is marked as stable before most bugs surface.

Side-by-Side Versions

A project can have references (direct and indirect) to several PostSharp/Metalama packages of different versions within the same major version. The version of the PostSharp/Metalama package must be higher than or equal to the version of any other package of the PostSharp or Metalama family. (Note that PostSharp and Metalama are totally independent product lines and have different release cycles.)

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. Code analysis warnings have been addressed for public APIs.
  7. Integration with new features and old features has been tested.
  8. All bugs with higher priority than Later have been fixed.

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

Our customers have three options to choose from when it comes to releases: Long Term Support (LTS), Current, or Preview releases. Here's what you need to know about each option:

  • LTS releases: These are supported for 5 years after the general availability date, or 1 year after a subsequent release has been promoted to LTS - whichever is shorter. Our LTS releases are designed to be used with the underlying LTS versions of the .NET and Visual Studio platforms, to ensure a complete and stable technology stack. However, there may be instances where certain features or platforms are no longer supported in a given release. These are referred to as "Exclusions" and may require an update to a subsequent release or have been abandoned altogether.

  • Current releases: These are supported for 2 months after the general availability of another Current or LTS release.

  • Preview releases: These include alpha releases and release candidates, and are supported until the next Preview, Current, or LTS release of the same minor version is published.

To be eligible for technical support, customers using the LTS option must have the latest patch update installed within the same minor release.

Version Release Date Support Level End of Support Exclusions
Metalama 2023.0 May 3rd, 2023 Current 2 months after some future Current or LTS version is released None
PostSharp 2023.0 January 12, 2023 Current 2 months after some future Current or LTS version is released None
PostSharp 6.10 December 1, 2021 LTS December 2, 2026 or 1 year after some future version is promoted LTS None

Supported Platforms and Frameworks

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 the Requirements and Compatibility page in PostSharp or Metalama documentation.

What we mean by supported platform

By supported (or officially supported) platform version we mean that we have spent or will spend commercially-reasonable efforts to:

  • test our product with these versions before or shortly after they are released,
  • fix issues that stem from the use of these versions, and
  • provide support services.

It frequently happens, in practice, that PostSharp or Metalama 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.

Support of platform versions by their manufacturer

Only platform versions that are currently supported by their manufacturer are supported by our products. 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:

Preview Releases

Pre-release platform versions are never officially supported, even when they get a production license from their publisher.

Patch Releases

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.

Abandon of support for platforms

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.

Support Level for Commercial Customers

Support Ticket

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