New 3.9alpha image is ready! (sort of)

[Bert Freudenberg]

Am 07.07.2005 um 08:35 schrieb Andreas Raab:

> Hi Doug -
>
>
>>> In Tweak we have basically a fixed load order (==configuration)  
>>> which originates from the configuration used in the original  
>>> build. But the main reason for wanting to have a well-defined  
>>> load order is that typically, if there are sets of cross-package  
>>> changes, they follow already established dependencies.
>>>
>> Yes, makes sense.  That should reduce the need for special update
>> changesets to load packages in a special order.
>>
>
> Yes. That's another implicit advantage - most of the time stuff  
> just "works" by loading the latest package versions.

Indeed - given that you have a "managed" repository, which has a  
linear numbering scheme and everyone agrees to merge in the latest  
version (so that when you upload v.n+1 it has v.n as ancestor). Maybe  
one could use squeaksource's blessing feature to enforce that.

So if you have cross-package changes, you just post all of them, and  
the load order is defined by the stored configuration (see below).

>> Any suggestions on how I should implement this?  I guess we could  
>> just
>> have a method defined somewhere (in the load-updates code) which  
>> has a
>> hardcoded, ordered list of the 35 package names.  I guess this list
>> won't change very often.  (The 3.9a-6676 image doesn't seem to be
>> hanging onto the MCConfiguration instance that was loaded in update
>> #6676, otherwise I might try to use that.)

That "hardcoded, ordered list of the 35 package names" would just be  
like the literal configuration that you issue as changeset (without  
the #upgrade call), but put into a method. It is precisely that  
literal representation why the configuration is as simple as it is  
now (compared to a full-blown MCVersion). It just defines a load  
order for a few packages, that's all :)

> What we've done so far is to have a global which stores the latest  
> version of a configuration and then just works issuing a  
> "updateFromRepositories". It's very simple stuff - if you are  
> curious check out CProjectBuilder>>loadUpdates and  
> updateFromRepositories.

Yep, this works nicely in Tweak. Pasting the methods below for easier  
reference. I stripped out the progress display and logging.

loadUpdates
        TweakUpdateStreamManager loadUpdates. "from update stream"
        self updateFromRepositories.

updateFromRepositories
     | map |
     map := self defaultConfiguration.
     [map updateFromRepositories.
     map upgrade.
     DefaultConfiguration == nil] whileTrue. "repeat if we have a new  
map"

defaultConfiguration
     ^DefaultConfiguration ifNil: [
         DefaultConfiguration := MCConfiguration fromArray: #(
             ...
         )]

There is a hook to set DefaultConfiguration to nil whenever the  
#defaultConfiguration method is recompiled (but this relies on Tweak  
semantics). Alternatively, you might have a class-side #initialize  
method that contains the new configuration, so it would automatically  
get overwritten after an update, and you test for map identity in  
#updateFromRepositories rather than testing for nil.

The call to #updateFromRepositories in #loadUpdates might possibly be  
guarded by a "bleeding edge" preference. That way, normal users only  
would get the "stable" configuratons explicitly posted to the stream,  
while the system developers would get all the latest packages from  
the repository.

- Bert -