New Versioning Scheme

At PostSharp Technologies, we have been early adopters of semantic versioning since 2013. However, looking back at the last 10 years, we think it’s time for a change. The main problem we have with semantic versioning is with the rule that links the bumping of the major version component to the introduction of breaking changes. In retrospect, we have noticed that we have always tried to maintain backward compatibility regardless of the major version component. Like most software houses, we accelerated our pace of delivery and now deliver a continuous stream of value rather than a major release every couple of years. In this context, a versioning scheme that imposes a strong difference between a major and minor version no longer seems to make sense, and we feel it’s time to join the industry trend of year-based versioning (or CalVer ), e.g. 2023.0.10, 2023.1.11-preview, 2024.0.20-rc.

We will now follow the scheme YYYY.N.B[-preview|-rc], 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,
• -preview indicates that the product is of pre-release quality and may still be subject to significant changes,
• -rc indicates that the product is of release candidate quality, which means that all quality gates for this version have passed and that we are waiting for more confirmation from users.

We will no longer make a difference between a major and a minor version, there will be just versions and builds.

Contrary to the SemVer specification, we will allow for breaking changes even when we will not change the YYYY component of the version number and will change the YYYY component even if we don’t have any breaking changes.

So, when do we do breaking changes? We don’t want to give hard rules, but we will apply practical judgment based on the following principles:

• We will never do a breaking change within a stable YYYY.N version unless it is absolutely necessary to fix a bug.
• Before removing an API, we will mark it as [Obsolete] and keep backward compatibility for some time.
• We will treat old APIs with more respect than new ones. We will not feel obliged to maintain a deprecated API longer than its non-deprecated lifetime, unless the API was included in a long-term-support (LTS) release.

We will apply this new versioning change in our next releases of PostSharp and Metalama.

Happy meta-programming with PostSharp and Metalama!