<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <pre wrap="">You want automatic upgrades to happen at any time? </pre> Yes, but only for the downwards compatible modules that don't break the API and if a developer chooses to do so. <pre wrap="">That seems a little risky to me! </pre> A risk a lot of companies provide you with with automatic upgrades. <pre wrap="">1. The program doing the requiring has been around and is already linked to version 1.4. In this case PLaneT does not (and I think should not) try to get a new version automatically ---- you have to ask. </pre> A new version of a module that is downwards compatible will either provide extra functionality, or provide bug fixes. It cannot by rule break the API syntax or semantics. <pre wrap="">2. The program doing the requiring is not already linked to a particular version, and there's no package already on the user's system that would satisfy the request. In this case PLaneT goes to the network.</pre> The obvious case :-) <pre wrap=""> * It increases the chance that the same package will get loaded twice with two different versions. This is a dangerous situation to be in, and currently PLaneT automatically prevents packages from being loaded twice with two separate versions unless the packages specifically announce that this is okay.</pre> That's not what I want. I want the latest package release to be downloaded when it is present of a certain API release, unless explicitly specified otherwise. One could e.g. use (require (planet "package.scm" ("author" "package.plt" 1))) That would always check for the latest release on start of a program (if it can, i.e. without delay); and download the latest package, if available. <pre wrap="">* It makes PLaneT connect to the network more often and download more packages. (The design tries to minimize this, though experience suggests that maybe nobody really cares.)</pre> It should not get in the way, i.e. block the startup of a program or increase the delay considerably. <pre wrap="">I'm not clear from your message what you're objecting to.</pre> I don't mean to be objecting. Sorry if I seem to be. I'm just proposing a new feature that will help in having an automatic distribution system. Hope this helps? --Hans Robby Findler schreef: <blockquote cite="mid20060710184755.D3B026BE3C@laime.cs.uchicago.edu" type="cite"> <pre wrap="">You want automatic upgrades to happen at any time? That seems a little risky to me! Or something else? I'm not clear from your message what you're objecting to. Can you provide a little more information, perhaps building on what Jacob writes? Robby At Mon, 10 Jul 2006 20:31:11 +0200, Hans Oesterholt-Dijkema wrote: </pre> <blockquote type="cite"> <pre wrap="">I think one should be able to choose. Currently, afaik, requiring a module is not bound to a specific program. I personally generally want the latest PLaneT package that is guaranteed to be downwards compatible, unless I really want to freeze my program (i.e. I'm distributing it to customers?). --Hans Jacob Matthews schreef: </pre> <blockquote type="cite"> <pre wrap="">Hans Oesterholt-Dijkema wrote: </pre> <blockquote type="cite"> <pre wrap="">If I release major=1 and minor=5, I would be very glad, if dependent modules would download the newer 1 5 version automatically. </pre> </blockquote> <pre wrap="">Currently PLaneT distinguishes between three cases: 1. The program doing the requiring has been around and is already linked to version 1.4. In this case PLaneT does not (and I think should not) try to get a new version automatically ---- you have to ask. 2. The program doing the requiring is not already linked to a particular version, and there's no package already on the user's system that would satisfy the request. In this case PLaneT goes to the network. 3. The program doing the requiring is not already linked to a particular version, but there is a package installed on the user's system that would satisfy the request. In this case, PLaneT currently uses the installed package --- I think you're suggesting that it shouldn't do that, preferring instead to check the network. I've thought about changing this behavior too, and I might do it. But there are two things to consider: * It increases the chance that the same package will get loaded twice with two different versions. This is a dangerous situation to be in, and currently PLaneT automatically prevents packages from being loaded twice with two separate versions unless the packages specifically announce that this is okay. * It makes PLaneT connect to the network more often and download more packages. (The design tries to minimize this, though experience suggests that maybe nobody really cares.) -jacob </pre> </blockquote> <pre wrap="">_________________________________________________ For list-related administrative tasks: <a class="moz-txt-link-freetext" href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> </body> </html>