Version and Support Policy

PostSharp and Metalama both support the current versions of .NET, C#, and Visual Studio, with a new long-term support (LTS) release about every two years. The table below shows what is supported today; the rest of this page covers our versioning scheme, servicing phases, and breaking-change policy.

Supported versions

Note

Metalama 2025.0 Extended Support builds, PostSharp 2025.0 Extended Support builds and PostSharp 2024.0 LTS builds will be available to anyone regardless of eligible support level.

For what each servicing phase means and how long it lasts, see servicing phases below.

Versioning and servicing phases

Versioning scheme

PostSharp and Metalama both follow the versioning scheme YYYY.N.B[-M], where:

• YYYY represents the current or next year,
• N signifies the version number within this year,
• B stands for the build number within the minor version,
• M is an optional suffix and denotes the release maturity level:
  • 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 stable releases, except that they have not been tested in the wild.
  • Stable (Generally Available/GA) releases have no suffix. They meet all quality standards, and the feature freeze applies. At this moment, the releases appear in the stable channels on our website, the Visual Studio Marketplace, and the NuGet Gallery, and they start to be widely downloaded.

We don’t differentiate between a major and a minor version. We only distinguish versions (YYYY.N) and builds (YYYY.N.B).

Warning

It typically takes 4 to 6 weeks after a new YYYY.N version is generally available before most bugs surface. Large teams working on tight deadlines are advised to wait for 8 weeks before updating to a new version.

Quality standards

We take the term release candidate seriously: an RC meets the same quality bar as a stable release, the only difference being that it has been less tested in the wild. Before we tag a 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, with both conceptual and procedural documentation.
4. Features have been tested on physical devices.
5. All public APIs have undergone extensive critical review.
6. Code analysis warnings have been addressed for public APIs.
7. Integration with new and old features has been tested.
8. All bugs with a higher priority than those marked later have been fixed.

Servicing phases

Each version goes through several servicing phases, which affect their eligibility and licensing terms. The servicing phases available to you are specified on the Entitlement Page.

To be eligible for technical support, you must use the latest build of any version available to you, except if a regression in the latest build prevents you from updating.

Long-term support (LTS) versions

LTS versions are designed to be used with the underlying LTS versions of the .NET SDK and Visual Studio platforms to ensure that the whole technology stack is as stable as possible.

Typically, we release an LTS version every second year, matching the pace of Microsoft’s platforms.

Breaking changes

• Within a version. We do our best to avoid introducing any breaking changes during the stable, extended support, or long-term support servicing phases. If we do introduce a breaking change nevertheless, this will be considered a high-priority bug.
• Between versions. We generally avoid introducing high-impact breaking changes between YYYY.N versions. However, we might occasionally introduce breaking changes in less-often used APIs between versions. These changes are documented.

Note

To avoid breaking changes, consider staying on an LTS version.

Using different versions side-by-side

A project can have references (direct and indirect) to several PostSharp or Metalama packages of different builds within the same version.

Side-by-side compatibility is provided on an “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.

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