On Feb 11, 2004, at 12:10 PM, Doug Way wrote:

> Adding the Monticello installer in Basic is another issue which 
> Michael & others posted about before.  I'm personally fine with adding 
> it.  That may make Monticello a defacto standard and it may viral 
> itself into a lot of code, but the same is true of changesets, and if 
> MC is a good addition/successor to the changeset format, maybe that's 
> a good thing.  (Life would be pretty difficult if we insisted on not 
> having ChangeSets or anything else as a standard, for example. :-) )  
> I'm still not totally clear on where the dividing line between MC and 
> PackageInfo is, I need to play around with MC more.  But it sounds 
> like we want the fuller capabilities of MC.

Note that what Göran was saying is that SM2 would pull in MCInstaller, 
which is *not* the full MC.  It's a single bootstrap class that lets 
you load MC packages as if they were changesets, and records some info 
about them that would be useful if the user later loaded MC.  Just 
having MCInstaller wouldn't allow us to actually update packages from 
SM properly, just install them into a clean image.  If we want to do 
this right, we will have to pull in Monticello itself the first time 
the second version of some package goes into the update stream.

I don't think we need to worry about a lot of code "virally" showing up 
in .mcz format - Andreas raised that concern way back and so we made 
sure the format inside the zipped .mcz file is a normal fileOut.  If 
all copies of Monticello somehow disappeared or stopped working you 
could just unzip the package file and pull out source.st.  The concern 
was more that our basic toolset would start depending on MC, and I do 
think we should be careful about this.  You should be able to unload MC 
at any point and have everything still work (except updating MC 
packages, of course), or we're doing something wrong.

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.

My biased $0.02,
Avi