I think the proposed workflow is good.<br><br><br><div><span class="gmail_quote">About these things:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> - How to manage the code and the changes? Most changes related to<br>> Compiler, CompiledMethod, Behavior, Traits, etc. cannot be loaded<br>> using Monticello.</blockquote><div><br>I think we must talk about "application package workflow".
<br>When You need to touch the Kernel or the SmallTalk compier, we need an "ad hoc" 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;">> - What to do with code that is not properly packaged yet? How to pass
<br>> 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>> - 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 "deprecated" 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 "deprecated" in some way.<br>For instance sending a message to <br>"Object deprecated" <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 "derived bugs"
<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, I suppose.
<br><br>So I think we must provide also a "deprecation" micro-workflow.<br><br><br></div></div><br><br clear="all"><br>-- <br>"Just Design It" -- GG<br>Software Architect<br><a href="http://www.objectsroot.com/">