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

[Simon Pilkington]

Max, thanks for your response.

> On 7 Dec 2015, at 12:50 PM, Max Howell <max.howell at apple.com> wrote:
> 
> 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.

I think this is a great approach, particularly for larger projects where even a dev familiar with the project can mistakenly change public API. Plus there is potential for things like automated release notes.

> 
>> This is probably only going to become an issue when dependency resolution is introduced
> 
> We already do dependency resolution.

My question actually related to dependency (sub-dependency) conflict resolution which is listed as future feature.

For example, considering the initial state

Module A -> depends on Module B v.1 (1.0.0) -> depends on Module D v.1
Module A -> depends on Module E v.1 (1.0.0) -> depends on Module D v.1

In this case you would get a consistent dependency graph and everything would correctly compile statically into Module A. But if Module E makes a minor version update so that

Module A -> depends on Module B v.1 (1.0.0) -> depends on Module D v.1
Module A -> depends on Module E v.1 (1.1.0) -> depends on Module D v.2

Without changing any code, Module A suddenly doesn’t have a consistent dependency graph, even if the changes to the public API of Module D don’t happen to impact the public APIs of Module E or Module A. Is this a concern or am I missing something here?

-Simon


> 
> Max
>