* Joachim Breitner
Hi,
Am Freitag, den 04.10.2013, 13:05 +0300 schrieb Roman Cheplyaka:
I have two concerns about versioning:
1. Suppose that package-a re-exports Data.Bar from package-b starting from package-a-2.0 and package-b-2.0. This means that we shouldn't prevent packages to be built with package-a-1.0 and package-b-2.0, because that would result in a duplicate module Data.Bar.
you mean „should“, right?
Yes, sorry.
I’m not sure if I understand your example. Does package-a-1.0 provide Data.Bar? Are you sure that this is not covered by the PVP?
The problematic situation could look like this: package-a-1.0 provides Data.Bar package-b-2.0 provides Data.Bar package-a-1.0.1 re-exports Data.Bar from package-b-2.0 Now, the change between package-a-1.0 and package-a-1.0.1 may seem almost invisible for the users, but if something depends on package-a ==1.0.*, package-b ==2.0 ... then we have a conflict in case package-a-1.0 is picked. But now I think this example is contrived because the constraint should really be package-a >= 1.0.1 && < 1.1 (we could only test our package successfully with package-a-1.0.1, and even ignoring module re-exports, package-a-1.0.1 could have added new entities).
2. If package-b has a major API change, it would bump its version, say, to 3.0. package-a still has version 2.0, but now it re-exports a completely different API.
Good point. But package-a depends on package-b, and hence a major API bump in package-b will require at least a new minor version of packaga-a. It is then the obligation of the author of package-a to check if the API changes affect the re-exported packages (and I hope that eventually we’ll have tools that help with that).
You are right again — I missed the fact that dependency package-a -> package-b itself has a version constraint. Roman