<!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<br>
the API and if a developer chooses to do so. <br>
<br>
<pre wrap="">That seems a little risky to me! </pre>
A risk a lot of companies provide you with with automatic upgrades.<br>
<br>
<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,<br>
or provide bug fixes. It cannot by rule break the API syntax or
semantics.<br>
<br>
<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 :-)<br>
<br>
<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<br>
present of a certain API release, unless explicitly specified
otherwise. One could e.g.<br>
use<br>
<br>
(require (planet "package.scm" ("author" "package.plt" 1)))<br>
<br>
That would always check for the latest release on start of a program
(if it can, i.e. without delay);<br>
and download the latest package, if available.<br>
<br>
<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.<br>
<br>
<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<br>
will help in having an automatic distribution system.<br>
<br>
Hope this helps?<br>
<br>
--Hans<br>
<br>
<br>
<br>
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>
<br>
</body>
</html>