About SqueakMap for 3.2 and the future!
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=
> 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=
> 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
> 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?
> 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. 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
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
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
More information about the Squeak-dev