"Edgar J. De Cleene" <[EMAIL PROTECTED]> writes: > ReleaseBuilderFor3dot10 new updatePackages: 'Collections-edc.90(89).mcd > CollectionsTests-edc.74(73).mcd > EToys-edc.25(bf.24).mcd > Graphics-edc.42(41).mcd > Kernel-edc.166(165).mcd > KernelTests-edc.58(57).mcd > Monticello-edc.313(312).mcd > Morphic-edc.129(128).mcd > MorphicExtras-edc.34(33).mcd > Multilingual-edc.29(28).mcd > Network-edc.34(33).mcd > ST80-edc.40(39).mcd > System-edc.109(108).mcd > Tests-edc.33(32).mcd > Tools-edc.85(84).mcd > Traits-edc.230(229).mcd > XML-Parser-edc.4(3).mcd' > > As you could see , if we do the update as now, the packages touched is huge. > I still don't test if the actual procedure could manage.
One thing that looks like could be easier for you would be to list these packages on the package universe. So you could have PU entries for CollectionsTests, EToys, Graphics, Kernel, etc. You can then post new versions of them as you like, and users can do "upgrade all" to get the newest versions. The only possible problem is when you are changing Monticello itself, or something that Monticello depends on. In that case, I suppose you have to fall back on change sets. For what it's worth, I use the above arrangement with Scala and it works just fine. You can do an in-place upgrade of both Scala and Scala's PU tool by running "sbaz upgrade". Lex _______________________________________________ V3dot10 mailing list [email protected] http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
