[Home](../../) › [Support](../../support.md) › [Support Policies](../policies.md) › Version and Support Policy # Version and Support Policy > Which versions of PostSharp and Metalama are supported today, how long each release is serviced, and our long-term support (LTS) commitment. Canonical: https://postsharp.net/support/policies/versions.html 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 | Version | GA Date | Servicing Phase | End of Extended or Long Term Support | Supported .NET / VS Versions| Details | |-------------------|-------------------|-----------------|--|----------------------------------------------------| | Metalama 2026.1 LTS | June 2026 | Current | 2 years after the next Metalama LTS is released (i.e., presumably, January 2030) | .NET 10.0 LTS, .NET 9.0, .NET 8.0 LTS, .NET Framework 4.7.2, Visual Studio 2022 (17.14), Visual Studio 2026 (18.0) | [Release Notes](https://doc.metalama.net/conceptual/release-notes/release-notes-2026-1) | | Metalama 2026.0 | January 2026 | Extended | December 2026 | .NET 10.0 LTS, .NET 9.0, .NET 8.0 LTS, .NET Framework 4.7.2, Visual Studio 2022 (17.12), Visual Studio 2026 (18.0) | [Release Notes](https://doc.metalama.net/conceptual/release-notes/release-notes-2026-0) | | PostSharp 2026.0 LTS | January 2026 | Current | 2 years after the next PostSharp LTS is released (i.e., presumably, January 2030) | .NET 10.0 LTS, .NET 9.0, .NET 8.0 LTS, .NET 6.0 LTS, .NET Framework 4.7.2, Visual Studio 2022 (17.12), Visual Studio 2026 (18.0) | [Release Notes](https://postsharp.net/blog/postsharp-2026-0-ga) | | PostSharp 2024.0 LTS | January 2024 | LTS | January 2028 | .NET 8.0 LTS, .NET 6.0 LTS, .NET Framework 4.7.2, Visual Studio 2019 (16.11), Visual Studio 2022 (17.4) | [Release Notes](https://postsharp.net/blog/postsharp-2024-0-ga) | > **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. Versions that are no longer listed above have reached the end of their servicing life and no longer receive fixes. For what each servicing phase means and how long it lasts, see [servicing phases](#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](https://store.postsharp.net/account). | Phase | Duration | License | Support Level | |------------------|-------------------------------------------------------------|---------|-------------| | Preview | Until the version is generally available. | Default[^1] | Community | | Stable / Current | Until a new version is generally available. | Default[^1] | Community | | Extended Support | Until 6 months after the next version is generally available. | Proprietary | Standard | | Long-Term Support | Two years after a subsequent release has been promoted to LTS or when the underlying platform version is no longer supported, whichever is sooner. | Proprietary | Enterprise | [^1]: The default license is open-source for Metalama (except for premium packages) and proprietary for PostSharp. 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. --- ## Site navigation - Previous: [Supported Components](components.md) - Next: [Service Levels](sla.md) - Index of the whole site: [llms.txt](../../llms.txt)