Semantic versioning of packages and supported compiler versions

[Paul Backus]

On Tuesday, 10 May 2022 at 12:21:43 UTC, Bastiaan Veelo wrote:
> In a [PR to 
> Pegged](https://github.com/PhilippeSigaud/Pegged/pull/311) we 
> are going to limit the supported compiler frontend to versions 
> 2.098.0 and newer, which at the time of writing is just seven 
> months old. My question is: *Should I release this as a patch 
> release, a minor release or a major release?* The change itself 
> is backwards compatible (adding `@safe` annotations).
>
> Projects that depend on Pegged following [semantic 
> versioning](https://semver.org/) that have it pinned to the 
> current major version, expect Pegged to be backward compatible 
> within that  major version, such that doing a `dub upgrade` 
> will not brake the build.
>
> Since this change *will* brake the build for anyone using a 
> compiler prior to 2.098.0 (be it with a clear error message by 
> using 
> [`toolchainRequirements`](https://dub.pm/package-format-json.html#toolchain-requirements) in our Dub configuration) one can argue that this demands a major version bump. So, should the major version number be increased with every change to `toolchainRequirements`, however minor? And would your answer be the same if the change would be reducing support for a very old frontend to a slightly less old frontend? If so, where is the cut-off?

In general, upgrading a dependency is not considered grounds for 
a major version bump in SemVer. So I would say you do not need to 
increment the major version in this case.

It seems like the real problem here is that dub does not take the 
installed toolchain version into account when resolving 
dependencies. If a user runs `dub upgrade` with DMD 2.097 
installed, dub should not select a package version that requires 
2.098.