I don't know how well tested/stable could be the closure change (expecially with third party packages as seaside, Magma or other DB backend) but if unsure it may be wise to keep it for a latter release, people may want first stability for a 1.0 to start productivity project with.

Hilaire


2009/5/11 St�phane Ducasse <stephane.ducasse@inria.fr>
>>>

Hi guys

Here are the discussions we forgot to get on the list :)


>> I was thinking that I would not do the license cleaning for 1.0
>
> Yes, I agree. We can do this in 1.1, which can follow shortly after
> 1.0. Any objections from Marcus, Mike?
>
> What is the status of "Main EToys removal, reorganize
> MorphicExtras-"? Do you plan to do more for 1.0?
>
> Apart from that we have left on our list (http://code.google.com/p/pharo/wiki/Milestones
> ):
>
> - default in-image font(s)
> - Package management system with stable and unstable distributions
> - Remove SqueakMap and Installer from core
>
> - All tests green
> - Clean up package and class category organization
> - Pharo one-click image (including developer tools, GettingStarted
> information, screenshots, ...)
> - New sources file
>
> Are we going to integrate the new preference system/browser in 1.0?
>
>> Now we are waiting for eliot closures changes.
>
> What kind of changes are theses? Did he say something about when
> they will be ready?

Stef

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
http://blog.ofset.org/hilaire