I think the proposed workflow is good.


About these  things:
>
> > - How to manage the code and the changes? Most changes related to
> > Compiler, CompiledMethod, Behavior, Traits, etc. cannot be loaded
> > using Monticello.


I think we must talk about "application package workflow".
When You need to touch the Kernel or the SmallTalk compier, we need an "ad
hoc" approach.
If something cannot be loaded I see only two solution:
A) De-couple the package so it can be loaded via Monticello
or
B) Act with an ad hoc approach

> - What to do with code that is not properly packaged yet? How to pass
> > code over to another package?

It must be packaged, at least with a primary release
.
SmallTalk tends to create very immersive packages:
You often find yourself modifiyng core classes.
This is not always the best option, but is also a Strong Feature of this
language.


> > - How to manage fixes that go across multiple packages?
>
> Package mantainers will have to coordinate for this, each applying the
> fixes to his package(s).


If you like a more nice solution, I suggest the "deprecated" way of life of
Java.
In Java when an API is obsolate is NOT removed at the next relased, but it
is marked as "deprecated" in some way.
For instance sending a message to
"Object deprecated"
can be a fair soltution to track them.
The deprecated method can do nothing and returns, and be used to track these
things.

This point is quite important.
I will stress it.
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"
We cannot force developer team to instantly adapt to core changes, even if
these changes are small and important.
The only exception is for security or stability holes.
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.
So code written for JVM 1.1 will run nicely until JVM 1.3.

In PHP is quite the opposite: they have broken compatibility every time.
And for this reason PHP relases are not done so often, because they must
give time to developers to migrate,  I suppose.

So I think we must provide also a "deprecation" micro-workflow.





-- 
"Just Design It" -- GG
Software Architect
http://www.objectsroot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061016/84e54d94/attachment.htm