Remaining to-do items for 3.7

goran.krampe at bluefish.se goran.krampe at bluefish.se
Thu Feb 19 09:20:06 UTC 2004


Julian Fitzell <julian at beta4.com> wrote:
> Avi Bryant wrote:
> > On Feb 18, 2004, at 9:29 AM, Lex Spoon wrote:
> > 
> >> Right, you beat me to it.  We can have a SqueakMap repository for each
> >> version of Squeak.  Then, the "RB" package in 3.6 is then different from
> >> the one for 3.7, and really we end up with multiple streams of package
> >> development.  You can populate each new SqueakMap repository by copying
> >> the old one.
> > 
> > 
> > That's a great idea.
> 
> Exactly what I thought!
> 
> Julian

Well... I am sorry to take the exact opposite position :).

I think it would be much smarter to simply enhance the model of SM. The
idea is that an SMPackage contains the correct "timeless" information
about the package. Then the releases contain the rest of the information
that may vary with releases.

Note that SM contains not only packages but accounts and soon other
entities as well. We do not want to have these things replicated in
multiple SMs. So no, I disagree and would instead like to think in terms
of making the model fit our needs.

For example, why not simply use filters smarter? I fail to see what
would need us to use multiple maps.

My suggestion: Let's take one step at a time here.

1. I will extend the loader in the upcoming release with some smarter
filters and defaults so that the "published" attribute has some meaning
and we can also use the categorization for filtering. This is thus
mainly a UI issue. The model is there already (categories, "published").

So when filtering for say "Squeak version 3.6" we can list only those
packages that have releases categorized under that version, and
subsequently only show those releases. And if the use only selects the
package (and not a release) and does "install" then he/she will get the
correct release for 3.6. Tada. No multiple maps needed for that.

2. We introduce a model of dependencies. I will work towards the model I
have proposed earlier.

3. Given step 2 above we can easily introduce a model with
stable/testing/unstable etc.

regards, Göran



More information about the Squeak-dev mailing list