Publishing on Monticello

Martin Wirblat sql.mawi at t-link.de
Fri Sep 16 20:08:24 UTC 2005


Andreas Raab wrote:
....
>> For publishing e.g. on SM you then would have to publish the modified 
>> version of the original package, too. It is probably big and has 
>> nothing to do with your application. As soon as the original changes, 
>> the modified version had to be synchronized. All that because of one 
>> changed method?
> 
> 
> Exactly! So you'd have to think hard to minimize the interaction with 
> the existing package and usually do something like convince the 
> maintainer of that package to add/change whatever you need to get your 
> job done. This is less convenient in the short term, but much more 
> robust in the long term 

Essentially you are saying here packages with overrides are to be damned 
on SM. Even if the overriding method had to be published in a modified 
original package, installing the combo would override the single method 
anyway. But I am ok with making such intrusive packages "second class" 
members of SM. I am not the one who expects magic from a dependency 
system ;) The real solution for all this is probably the opposite of 
version and branch inflation, namely self-restriction and simplicity. In 
short words: Working towards a *single* image release, modularized in 
itself and for the "outer ring" Lex' universe of arbitrarily loadable 
packages, where it is only needed to take care of "positive" dependencies.

....

>> For all other purposes that want to derive from a master but want to 
>> develop with the master (and that is the standard case), some sort of 
>> "delta functionality" is needed. This delta should be as smoothly as 
>> possible addable to the next version of the master, because this work 
>> has to be done manifold (by the millions of the future, that are going 
>> to use Squeak:)
> 
> 
> I think that's very arguable. You are right of course, that for a user 
> this should be smoothly to install, but for a developer, should the 
> system really allow you to mess up an (end-)users installation just 
> because you are lazy? Remember, the poor end-user has probably no idea 
> why installing one app broke another one...
> 

Here I must disagree vigorously, remember this is the private version. 
Perhaps I exaggerated a bit with millions and misguided you to thinking 
of users of the out of the box Squeak. So this is about Squeak using 
programmers, who want to change the official base system, the master 
line, for their own needs, but want to be able to as easily as possible 
keep in sync with the official releases. My very elementary example was 
tweaking the UI of Squeak a bit :) This is by Monticello not really 
supported, but such a facility is the logical evolution of Smalltalk the 
single user desktop system in which you can modify everything you want.

And who knows, perhaps there is even more in the cards with such a delta 
functionality, like being able to make a short-lived-fork release that 
every new main release gets "reforked" like Avi once proposed.

Regards,
Martin



More information about the Squeak-dev mailing list