Proposal for the coming versions

Andreas Raab andreas.raab at gmx.de
Tue Mar 14 10:15:14 UTC 2006


Cees de Groot wrote:
>> Um ... I might be slow or something but can you explain to me again how 
>> this makes things simpler/easier/whatever? Where is (in terms of pain 
>> associated with it) the difference between having that MCC map and 
>> posting it to an update stream? (unless you don't do it at all ;-)
>>
> Well... in the update stream, you need to take care about load order,
> about conversion scripts, stuff like that. Just a map won't be enough
> to upgrade X to Y. For example, loading your UI work (ToolBuilder
> etcetera) was relatively easy, not in the least because it was
> well-prepared and well-documented. Loading it in a way that was
> perfectly reproducable in an automatic way (ie "scriptable") took
> quite a bit of time, it had to be split up over multiple update stream
> versions, so it was a general pain to take that extra step.

I still don't quite get what you're saying. Was there any "extra effort" 
associated with "making it perfectly reproducable in an automatic way" 
(I'm quoting it because I don't understand what was involved in this 
process) other than simply posting a "load this package" command? In 
other words, what I don't understand (or don't know about) is what extra 
effort was needed to get the packages in a form suitable for the update 
stream?

>> Nice try. You know just as well as I do that this ain't gonna happen ;-) 
> 
> It depends. Personally, I don't think it is fair to burden the release
> team with lots of work that maybe only others care about. That's why

"only others care about" - "others" like in "customers"? I'd be careful 
not to underestimate the interest of the casual Squeaker to just check 
out what's going on in the latest versions. Not necessarily always 
riding on the latest alpha but being able to "check in and see" where 
things are.

> I'm trying to find a process (and - remember the original mail -
> implement that in 3.10) that minimizes the burden on the package and
> especially release teams. If people complain that this won't satisfy
> their crave for software archeology, let them step up and do something
> about it (yup, exaggerating there - the points you point out are valid
> but are they important enough?).

Good question. It is important to put the options squarely on the table 
though, and in this case (and both Daniel and you in a response to 
Daniel's post agree on that) it really means that this proposal is 
essentially the end of the ability for anyone to update their images 
automatically (which is really behind my comment, e.g., how likely is it 
that somebody will retrace the steps after the fact to make it loadable).

Whether that is "important enough" or not is a good question. One thing 
I believe is "important enough" however is the documentation aspect of 
being able to update on your own. The main value here is that anyone can 
review what changes have been done in any version and can follow along 
and see where things stand, what has been changed and how. That's not to 
say that the update stream is the only way to deal with that but given 
the diverse set of people dealing with different releases I think it's 
critical to have the process documented in some form. If the way in 
which image vX.Y+1 was derived from vX.Y is unclear I think we're in for 
trouble.

Cheers,
   - Andreas




More information about the Squeak-dev mailing list