[squeak-dev] Re: Nebraska-edc.15 in trunk unloadable

Ken Causey ken at kencausey.com
Sat Jul 18 16:35:15 UTC 2009


On Fri, 2009-07-17 at 21:54 -0700, Andreas Raab wrote:
> Ken Causey wrote:
>  > P.S. One thing the new update stream does appear to lack compared to the
>  > old update stream is the ability to easily update only up to a certain
>  > update number.  Is there some way that could be implemented?  Clearly
>  > the trunk is not the simplistic linear thing the old update stream was.
> 
> We can do that and it's certainly worth considering. All it would take 
> is to not do the last part of the above description, i.e., do not update 
> beyond what is listed in the last configuration.
> 
> The consequence of the approach would be that once you've pushed a 
> change and it works you need to do an additional step and update the 
> configuration to include that package. If people feel it would be safer 
> to work that way, it would require only a tiny modification of the 
> script, at the cost of requiring two steps before a change really 
> reaches everyone who updates.
> 
> Comments? Preferences? Opinions?
> 
> Cheers,
>   - Andreas

I'm not certain if we are talking about the same thing here.  I'm
thinking of an analog to

Utilities class>>updateFromServerThroughUpdateNumber:

and this would be done from the user side as desired.

I think I still don't quite understand MC configurations because the
model in my mind was simply that the .mcm specified packages and not
specific versions and that when you updated it updated all listed
packages to the latest versions in the repository.  However I just
looked at the latest update-ar.4.mcm and it does indeed specify
versions.  So that confuses me why we don't have to modify the .mcm
every time a new version is published.

Perhaps a way to do what I want could involve specifying a local
override to specific entries in the the mcm to only update to a certain
version of a package or perhaps not even load a package at all.

What I'm thinking of is something that I would expect to only rarely be
used and I wouldn't want to increase the effort required for each update
to the trunk to support a rare action.

Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090718/9f8aadce/attachment.pgp


More information about the Squeak-dev mailing list