On Feb 11, 2004, at 1:10 PM, Colin Putney wrote:

>
> On Feb 11, 2004, at 3:40 PM, Avi Bryant wrote:
>
>> I guess the question is whether we want to continue having the 
>> ChangeSet as the One True Format that gets to go into the update 
>> stream (and convert everything else to it, like the MC->.cs 
>> transation service that Marcus suggested), or whether we want to 
>> allow for the possibility of alternate update formats.  Obviously we 
>> have to have support in the image for any formats we put into the 
>> update stream, so we shouldn't be too loose about what we accept.  
>> But if a lot of code does start appearing in a certain format (.sar, 
>> .mcz, maybe Rosetta somewhere down the line), I don't see a problem 
>> with allowing it into the stream.
>
> I think the update stream should continue to be change sets only.
>
> What we need to work on is making other update mechanisms equally easy 
> to use and creating distribution images that contain code not managed 
> by the update stream.

But the update stream still defines the "version" of the image as a 
whole, and is likely to continue to do so for a while anyway.  I think 
there's value in being able to describe the base state of someone's 
image (before any packages they've loaded themselves) as a single 
integer.  What I'd like is for that integer to imply "has updated to 
version X of package Y" as well as "has loaded changeset number N".  
That means getting packages into the stream.

Now we don't need to literally put the whole package file into the 
stream, just a doIt that loads it from somewhere.  Though either could 
work.