I'm sorry about that. This is true that the addition to MC are quite
draft but useful and not tested
on large scenario.
I imagine myself really doing the same.
On Apr 19, 2009, at 5:43 PM, Nicolas Cellier wrote:
> I experimented other unaware beotian stupid manipulations (just to
> workaround the oter bug) :
>
> 1) modify Kernel
> 2) add a SLICE-A requiring Kernel
> 3) Publish SLICE-A -> SLICE-A.1 Kernel.1
> 4) modify Kernel again
> 5) add a new SLICE-B requiring all dirty packages, that is Kernel
> and SLICE-A
> 6) Publish SLICE-B -> SLICE-B-1 Kernel.2
>
> Now SLICE-B.1 depends on SLICE-A.1 and Kernel.2
> BUT SLICE-A.1 depends on Kernel.1
>
> 7) quit the image, restart and load SLICE-B.1
>
> Doing this, I ended up with Kernel.1 in the image... GRR
My advice is:
if your changes in simple and touch only one package don't bother
create
a slice even if this is cool because I clean regularly the inbox and
sometimes it is difficult
to understand what is what.
if your changes touched a lot of package slice is important.
Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
