In a PR to Pegged 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 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 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?

-- Bastiaan.

On Tuesday, 10 May 2022 at 12:21:43 UTC, Bastiaan Veelo wrote:

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.

On Tuesday, 10 May 2022 at 14:35:06 UTC, Paul Backus wrote:

You make an interesting point.

-- Bastiaan.

On Tuesday, 10 May 2022 at 12:21:43 UTC, Bastiaan Veelo wrote:

(We have postponed this for now as the PR supports both old and new using static if.)

-- Bastiaan.

On Tuesday, 10 May 2022 at 14:35:06 UTC, Paul Backus wrote:

That would be a nice feature to be able to list dmd as a versioned dependency, or any other tool that will be used during build.