(Sorry for double post, forgot to respond to another point) Regarding using semantic version to resolve correct dependencies: what do you do when a codebase needs two different versions of a package? Suppose your app depends on packages A and B, but both A and B depend on C. More specifically, they depend on different versions of C. Under the current system, assuming a package and it's clients are "well behaved", either A and B both depend on C without problems, or either A or B depends on C2, which installs different collections than C.
This can be fixed by allowing multiple versions of a collection to be simultaneously installed, but that feels really tricky. Additionally it does nothing about a single *module* that depends on both C and C2. I feel like the best advantage of the current system is if there's breaking changes to C, I can say my package depends on *both* C and C2, and then *selectively* update individual pieces of code in my package. If I want to completely move to C2, then I just remove the dependency on C and look for broken things. Whatever happens moving forward, I'm interested in keeping that feature. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/35130451-7119-4612-bd10-092515ce7ec9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
