[TFNR][REPORT]Where are we?!

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Nov 19 08:44:17 UTC 2003


ducasse <ducasse at iam.unibe.ch> wrote:
> Hi goran
> 
> This morning I was asking myself a question (you know doing boring 
> exercise to try to get muscle
> let your mind wandering ;)
> 
> will I be able to send to somebody a package alone? for example for my 
> book I cannot assume that
> school have a net connection?

Well, depends on what you want to do.

> Once you mentioned that we will have a local copy of the map. But why 
> do we need that if we have all the
> elements required? I like for example the idea behind parcel in VW.
> Then I was thinking to you point to have separation between package and 
> configmaps.My impression
> is that (1) I'm really curious to see how many package will have more 
> than one config (but I can live with

Packages don't have configs - package *releases* do. :) But you probably
meant that.
Well, I think they will turn out to have more simply because the
packages that your package depends on *evolves*.

So you have your package Banana, released in 1.0 that has one config
referencing Apple 1.0 and Oragne 1.1.

Banana 1.0
   Apple 1.0, Orange 1.1

Now, what will happen is that John releases Orange 1.2. And someone
tries using it with Banana. And it works. Suddenly we have:

Banana 1.0
   Apple 1.0, Orange 1.1
   Apple 1.0, Orange 1.2


So you see - there will easily be more than one. In fact - I could even
imagine having "anti-configs" - which is a config someone tested that
*DIDN'T* work. But one step at a time, right? :)

> your idea (2) you will have to release and version configmap anyway so 
> the solution to have groups package and
> config maps is that one package has several configmaps and that the 
> versioning of a configmap does not
> produce a version of a package but the opposite yes. This way mulitple 
> persons can have multiple
> config maps with different versions on the same package having the same 
> version.

I am not sure I follow - but configurations aren't meant to have
versions. Sure, they will have a field with a version String - but SM
will not track old versions of them. They will be like "packages" on SM1
is today.

> This is only when you release
> a new version of the package that you change it.

Yes. The only reason to release a package is when it has actually
changed content. True. And as it should be IMHO.

> Stef

regards, Göran



More information about the Squeak-dev mailing list