New 3.9alpha image is ready! (sort of)

[Doug Way]

On Jul 7, 2005, at 6:16 AM, Bert Freudenberg wrote:

> Am 07.07.2005 um 08:35 schrieb Andreas Raab:
>
>>> 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 :)

Right, sounds good.

I haven't tried adding this yet to the update stream.

This may become obvious when I look into it, but I assume this MC 
configuration will load the very latest versions of each package, not 
necessarily the specified versions?  (That's what I was looking for... 
a simple "load order" configuration and not a configuration that only 
loaded specific versions.)  I think that's what the #upgrade does if I 
remember right, but I'll have to try it.

I assume the CProjectBuilder class below is in a particular Tweak 
package.  Meaning that if you wanted to change the list of packages in 
#defaultConfiguration, the #defaultConfiguration method in that package 
would be updated.  (In other words, that particular package would sort 
of store the configuration.)  But I guess it wouldn't change that 
often, if it was simply used for the load order (and didn't have to be 
updated every time one package in the list bumped versions).

- Doug


>
>> 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.