Versioning and servicing phases
Versioning scheme
PostSharp and Metalama both follow the versioning scheme YYYY.N.B[-M], where:
YYYYrepresents the current or next year,Nsignifies the version number within this year,Bstands for the build number within the minor version,Mis 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 major version.
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.
| Phase | Duration | License | Support Level |
|---|---|---|---|
| Preview | Until the version is generally available. | Default1 | Community |
| Stable / Current | Until a new version is generally available. | Default1 | 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 versions is no longer supported, whatever is sooner. | Proprietary | Enterprise |
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.
Version status
| Version | GA Date | Servicing Phase | End of Extended or Long Term Support | Supported .NET Versions |
|---|---|---|---|---|
| Metalama 2025.1 | May 2025 | Current | 6 months after the next stable release of Metalama is published | .NET 9.0, .NET 8.0 LTS, .NET 6.0 LTS |
| Metalama 2025.0 | January 2025 | Extended | November 1, 2025 | .NET 9.0, .NET 8.0 LTS, .NET 6.0 LT |
| PostSharp 2025.1 | May 2025 | Current | 6 months after the next stable release of PostSharp is released | .NET 9.0, .NET 8.0 LTS, .NET 6.0 LT |
| PostSharp 2025.0 | January 2025 | Extended | November 1, 2025 | .NET 9.0, .NET 8.0 LTS, .NET 6.0 LT |
| PostSharp 2024.0 | January 3, 2024 | LTS | 1 year after the future version is promoted LTS | .NET 8.0 LTS, .NET 6.0 LTS |
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.
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.Nversions. 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.