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
|