[squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)

Bernhard Pieber bernhard at pieber.com
Sun Jun 28 22:47:04 UTC 2009


Thanks for the answer, Keith.

I just realized that your goals and those of the Pharo leaders seem to  
overlap quite a lot. Small base image, automatic build, build up  
images with scripts from packages. The main difference being backwards  
compatibility, right?

Cheers,
Bernhard

Am 28.06.2009 um 22:17 schrieb Keith Hodges:

> Dear Juan,
>> Ok. So, what does that set of objectives and agenda say about:
>> - Backwards compatiblity
> We have had Installer, and LevelPlayingField for ages. The purpose of
> which is to make some compatability possible between different images,
> and ongoing changes to API's can be back ported to other images thus
> preserving backwards compatability, and providing forwards  
> compatability
> where possible.
>
> We have more backwards and forwards compatibility now than we ever had
> before.
>
> The crux of the difference between squeak and pharo philosophies has
> been the issue of backwards compatability.
>> - Removal (or not) of stuff
> All tools we are using for 3.11 are not reliant upon a gui. This is
> explicitly because the stated goal has been for at least 3 years to  
> work
> towards a kernel image, with which people can build up the custom  
> image
> that they want.
>> - Addition (or not) of stuff
> The proposal is to have a range of deliverables for different goals,
> from minimal images to fully loaded images for testing.
>> - Modularity
>> - Any concrete statement (about the software, not the process!) so
>> people can know what to expect
>> ?
> This statement has been that 4.0 would be as 3.10 with minimal changes
> for relicencing purposes.
>
> 3.11 has been proposed as an image with minimal changes, that would be
> proof of concept for the new process.
>
> a) Readies the image for automated build and testing - i.e. release
> early and often will be properly possible at last
> b) Readies the image for our automated/open mantis integration for  
> bug fixes
> c) Hopefully includes atomic loading for making radical changes to the
> image possible (i.e. new gui/compiler etc)
> d) Readies the image for future releases that are assembled by a
> selection of components, working to a design proposal rather than by  
> an
> infinite set of incremental changes by one or two control freaks.
>
> (p.s. I need help someone to test and debug (c))
>
> The actual "design" as to what 3.11 results in has been in the form of
> executable code for over a year, in the ss/Tasks repository. This is
> probably looking a bit stale now since I have been working on bob.
>> When was it approved by the community or the elected leadership?
> ages ago.
>
> http://installer.pbworks.com/Squeak311Proposal
>> Was there a decision process involving the community?
> http://installer.pbworks.com/Squeak311
>
>
> Keith
>
>
>
>




More information about the Squeak-dev mailing list