[swift-build-dev] Dependency consistency within package major version

[Max Howell]

Hi Simon.

> It looks like a module could in theory change dependencies on a minor version or patch change but only to the resolution of a major version.

Specifically, a package could change its dependencies at any version revision. Though in practice an end-user should choose packages from authors they trust to not make such changes without care.

> This is probably only going to become an issue when dependency resolution is introduced - where changing dependencies has the potential to suddenly break the consistency of a dependency graph of an unchanged consumer; are modules going to be required to stabilise their dependency graph within a major version?

Indeed, a Package’s dependencies can be changed at any version bump. This is OK because: should a dependency bump its major version it will cause your Package’s major version to bump if that dependency is exposed as part of your Package’s public API. For example:

class Dependency {
	func foo()
}

// Your package

class Consumer {
   func bar() -> Dependency 
}

// Now if Dependency changes its major version:

class DependencyNameChanged {
}

// Your package will have its major version changed also:

class Consumer {
   func bar() -> DependencyNameChanged 
}

This is hard to detect for users and a source of dependency hell, which is why I strongly desire for the versions of our packaging system to be calculated computationally via tooling we write.

At this time correctly versioning packages is up to the authors; a non-ideal situation because it is *hard*.

> Expanding on the 'Enforced Semantic Versioning’ section of the proposal doc, a dependency change could be detected and treated the same as a change in the signature of a public method but this section doesn't explicitly mention how or if dependencies will be taken into account for versioning.

I hope my above example clarified how this would work. We will be examining the AST (or equivalent) and determining version changes that way, so in theory the above would not have triggered a major version bump if the specific class had not changed its public API. Though I think in practice this is rare.

> This is probably only going to become an issue when dependency resolution is introduced

We already do dependency resolution.

Max