I think the proposed workflow is good.<br><br><br><div><span class="gmail_quote">About these&nbsp; things:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt; - How to manage the code and the changes? Most changes related to<br>&gt; Compiler, CompiledMethod, Behavior, Traits, etc. cannot be loaded<br>&gt; using Monticello.</blockquote><div><br>I think we must talk about &quot;application package workflow&quot;.
<br>When You need to touch the Kernel or the SmallTalk compier, we need an &quot;ad hoc&quot; approach.<br>If something cannot be loaded I see only two solution:<br>A) De-couple the package so it can be loaded via Monticello
<br>or<br>B) Act with an ad hoc approach<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; - What to do with code that is not properly packaged yet? How to pass
<br>&gt; code over to another package?</blockquote><div>It must be packaged, at least with a primary release<br>.<br>SmallTalk tends to create very immersive packages:<br>You often find yourself modifiyng core classes.<br>
This is not always the best option, but is also a Strong Feature of this language.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>&gt; - How to manage fixes that go across multiple packages?<br><br>Package mantainers will have to coordinate for this, each applying the<br>fixes to his package(s).</blockquote><div><br>If you like a more nice solution, I suggest the &quot;deprecated&quot; way of life of Java.
<br>In Java when an API is obsolate is NOT removed at the next relased, but it is marked as &quot;deprecated&quot; in some way.<br>For instance sending a message to&nbsp; <br>&quot;Object deprecated&quot; <br>can be a fair soltution to track them.
<br>The deprecated method can do nothing and returns, and be used to track these things.<br><br>This point is quite important. <br>I will stress it.<br>If, for instance, we change the Socket class we cannot throw away the old API, or even Seaside or SmallWiki will have problems and &quot;derived bugs&quot;
<br>We cannot force developer team to instantly adapt to core changes, even if these changes are small and important.<br>The only exception is for security or stability holes.<br>In Java you have a release to fix things. For instance a deprecated method in JVM 
1.2 is removed in JVM 1.3, but you can leave it.<br>So code written for JVM 1.1 will run nicely until JVM 1.3.<br><br>In PHP is quite the opposite: they have broken compatibility every time.<br>And for this reason PHP relases are not done so often, because they must give time to developers to migrate,&nbsp; I suppose.
<br><br>So I think we must provide also a &quot;deprecation&quot; micro-workflow.<br><br><br></div></div><br><br clear="all"><br>-- <br>&quot;Just Design It&quot; -- GG<br>Software Architect<br><a href="http://www.objectsroot.com/">
http://www.objectsroot.com/</a>