Interpretation of SemVer spec

[esthermations]

Hi, I got a bit confused by the section in README.md about SemVer:

Semantic Versioning provides a rule for version numbers:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

The point is that a given crate A made to depend on version 1.2.3 of another crate B, can safely be compiled with version any of B between 1.0.0 and 2.0.0. Alire uses this system to find releases that satisfy all the dependency requirements of the different crates used.

I might be wrong about what constitutes an "incompatible API change" versus what is "backwards compatible", but I think this paragraph contradicts the quoted semver spec.

For example, if we have:

--  Thing 1.0.0
type Thing is private;
procedure Move (T : in out Thing); -- added in 1.0.0

And we make the following change:

--  Thing ?.?.0
type Thing is private;
procedure Move (T : in out Thing); -- added in 1.0.0
procedure Spin (T : in out Thing); -- added in ?.?.0

My reading of the spec says this new version should be called 1.1.0, because code that depends on 1.0.0 (and therefore doesn't use Spin) can still use 1.1.0 code without noticing any change.

However it is not true here that a crate made with a dependency on 1.1.0 will always compile with 1.0.0, because it may use the newly-added Spin function.

That README section provides examples of new procedure arguments being added, but with a default value to provide backwards compatibility:

procedure Print (Str : String);

into

procedure Print (Str : String; Indentation : Natural := 0);

and says that this should be a minor version number increment. But if this is 1.1.0, and a user depends on 1.1.0 and their code contains Print (Str => S, Indentation => 5); then their code will not compile with version 1.0.0.

I just thought I'd bring that up - that first paragraph seems to contradict the semver spec, and even the following example code. If Alire indeed uses that logic for dependency resolution, it seems like a serious issue. But I might be missing something. Just thought I'd mention it.

Thanks.

[mosteo]

What you explain is true for both examples, but someone using the new additions should also update their dependency from ^1.0 to ^1.1, and this will indeed require a minimum of 1.1. Not sure if I'm missing something from what is in the README.