Hi, > Suppose we had a semantic notion of which packages were intended to be > "top-level" versus used as a dependency, and we chose our defaults > accordingly (in this case, we would orient workflows towards pinning by > default in the top-level case, in the used as a dependency case we would > orient away from it, e.g. warning you if you checked it in). What would you > think of such a design?
What is wrong with checking in the versions of your dependencies even if you are not a top-level package? That’s a great way to document which versions do work together and may be helpful for the maintainer of the top-level package which is depending on you (he can easily compare the version files to find problems). I think we agree that `swift package` within the top-level project should not look at the Package version files of its dependencies. So these files will not change anything for the top-level builds. I really think that the easiest solution is to always store the versions of all dependencies in SCM. Then have some `swift package update` to move all versions to the latest consistent set and we have everything we need. Each package can be built reproducibly and can be managed independently. If packages want to track their dependencies closely, then simply set up some CI which does the update automatically. You could automatically create create ‚update‘-commits, test them and automatically merge them if you really want to. But every update is documented and you can even bisect bugs which were introduced by the updates. This is helpful both for top-level as well as for library projects. — Martin _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
