About SqueakMap for 3.2 and the future!

Colin Putney squeak-dev at lists.squeakfoundation.org
Mon Oct 28 20:56:07 UTC 2002


On Sunday, October 27, 2002, at 11:06  AM, G=F6ran Hultgren wrote:

> Ok, what about the "thinking" part?
>
> *Personally* I have come to the conclusion that Modules in 3.3a is=20
> dead. I tried
> to fool myself into thinking that it could get picked up by the rest=20=

> of us but
> after having seen Andreas and Daniel struggle and more or less "give=20=

> up" (I may
> be wrong in this but that is my perception) then... ;-) I have a hard=20=

> time
> seeing anyone else succeeding.
>
> Again *personally* I think we should just face this truth, declare=20
> 3.3a as a
> dead branch, start harvesting as much as possible over to 3.2 from=20
> 3.3a (forming
> 3.4a?) and then try to look over the stuff in Modules and see what we=20=

> can easily
> copy or learn from it. During this we should start ripping out pieces=20=

> of 3.2 (in
> 3.4a that is) into packages of their own in SqueakMap. Using DVS and=20=

> SqueakMap
> this is clearly possible today.

I've kept pretty quiet during this modules discussion, though I've=20
followed with interest. But I've got to chime in to support this=20
conclusion. I've steered clear of 3.3 because it's so impenetrable, but=20=

I'm getting along nicely in 3.2 using DVS and CVS to maintain my=20
packages. With SqueakMap to make finding and installing packages really=20=

easy, it's now feasible to think about factoring the image into=20
packages.

> So, I would like to come up with some answers to these questions:

Here's my two bits:

> 1. Should we dump Modules? If not then how do we make Modules work?

Yes.

> 2. If we dump Modules, what do we do with 3.3a? Is it even possible to
> reconstruct it easily? Is it better to simply freeze and salvage stuff=20=

> from it?

Without intimate knowledge of the state of 3.3, I'd suggest this:

- freeze 3.3
- backport to 3.2 any non-Modules work that has been done
- harvest the Modules code that can be usefully applied to packages in=20=

3.2.

> 3. If we dump Modules, how do we proceed with the lightweight route?

G=F6ran mentioned adding the following features to SqueakMap:

- registering and updating packages from within Squeak
- versioning of packages
- per-package update streams
- inter-package dependencies and/or configurations
- cleaner UI / model separation to allow alternate UIs.

All this stuff makes sense to me, and should be part of a feature=20
complete SqueakMap.

I think the missing piece in all this real versioning of Smalltalk code=20=

in Squeak. SM should handle versioning of package releases, but for=20
development purposes, we need a real SCM along the lines of ENVY or=20
StORE.

Drat. Cees just beat me to the punch.

Anyway, I've been thinking about how to do this. If we put our heads=20
together at OOPSLA we can come up with a plan for going forward with=20
packages.

Cheers,

Colin



Colin Putney
Whistler.com




More information about the Squeak-dev mailing list