When we ask how important the update stream is, I think we need to 
separate two questions:
-How important is it to be able to update every image forever across 
versions?
-How important is it to be able to update most of the time, and only get 
a new image once or twice per release when things break?

The latter is enough for the "keeping up with current events". The 
former is what we need for "I don't care if I can export/import my 
objects, I'll just upgrade the image" or for creating "history images" 
which have full versions and so forth.

This is a scenario I worry about, and maybe I shouldn't: how should we 
handle things like the Traits transition? if all we do is put out a new 
image, then for (for example) Croquet to get Traits, for example, they 
need to either do the same process themselves (but we didn't require 
anyone to document the process, just put out a result) or take the new 
squeak-dev image and turn it into Croquet.

Adrian and I worked pretty hard to make the Traits transition 
reproducable, so it can be redone in other projects. So this is 
possible, but it is sometimes a lot of work.

Is this issue important enough to do this work?

Daniel

Andreas Raab wrote:

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