[V3dot10] Re: About a big change

[Lex Spoon]

"Edgar J. De Cleene" <edgardec2001 at yahoo.com.ar> 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