On Sep 2, 2015, at 2:17 PM, Jack Firth <[email protected]> wrote: > > It's conceivable that the package info lookup API with the catalog > could include "I want version X", but because new versions are defined > to be backwards compatible, as long as the server has some version > that's after X, then there is no reason to know what any old version > has, since any client should be happy with any release >X. > > There will be packages that aren't backwards compatible however. A simple bug > fix could break a workaround in another package, and a rearranging of the > internals of the package's collections could break packages depending on the > private implementation of the collections. One person's non-breaking change > may be another person's breaking change. This is going to happen, there's no > way to completely prevent it. What do we do when that happens? It seems > problematic to me if there's no easy way for package clients to lock > themselves into a particular version and rely on the package catalog to > guarantee they won't get anything else.
To do that, you can put the package source for the specific version (instead of the name) in the deps specification, and if the package isn't already installed, it goes to that package source instead of through the catalog. That doesn't work if the user already has the newer version installed though, because it would just assume the newer version will work. -- 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/CF26B25F-FDF5-42E5-897D-6193CA559D8B%40knauth.org. For more options, visit https://groups.google.com/d/optout.
