A roadmap on Squeak.org would make sense. It's also desirable for any newcomers willing to invest considerable time on a project based on Squeak.

Ian.

2008/12/8 Ken Causey ken@kencausey.com:

We are considering setting up a Roadmap of some sort on squeak.org, but for now see

http://installer.pbwiki.com/311

Ken

On Mon, 2008-12-08 at 10:12 -0600, Tim Johnson wrote:

...

Hi,

Off Topic: Looks like there is debate stirring among the Ruby community on whether to fork Ruby to experiment with parallelization, etc. Sounds awfully familiar.

http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-rubymy-rubyconf-...

On Topic: A Google search for "squeak roadmap 3.11" turns up no applicable results. Is there a formal roadmap? I am most curious about what will happen to 3.10 when 3.11 is released.

Thanks, TimJ

I was asked for a clearer explanation... :-) so here goes...

========= SakeTasks - The shortest summary I could come up with.

A package inspired by Make and ruby's Rake.

It runs tasks. Tasks consist of actions (blocks or tasks), in an order as defined by dependencies (blocks or tasks), if the "ifs" (blocks returning true/false, or tasks which succeed or fail), indicate that the task is necessary.

Images can be updated, and new releases generated via TasksRelease-c-#task* methods in which bug fixes held on mantis are called up as dependencies..

============== Here is an example:

ReleaseAfterSqueak310-#taskLoadSomething

^ self define: [ :task |

task dependsOn: {

self fixOneDay: '0000 Some bug not included, placeholder only'.

self fixUnstable: '1111 Some bug to be included in the Unstable Build of the next Release'.

self fix: '2222 Some bug fix to be included in Next Release'.

self fixEssential: '3333 Some bug to be included in any future Updates'.

}.

task action: { Packages current load: 'Something' } ]

============

In the example, a package is to be loaded:

"Packages" contains every Package in Universes, every Package in SqueakMap, and it can automatically attempt to find the latest code for packages that are defined in Universes.

Packages also contains sets of packages like Damien's dev image, as maintained by Damien himself. So derived images (e.g. -fun -full -max -test -seaside -dev and -web) can all be generated from package lists maintained by (insert your name here) in Universes &/ Sake/Packages. e.g.

Packages current load: 'Squeak-dev image',

To use the feature that hunts down the very latest code available for all the packages in Damiens image use #beta instead of #current.

Packages beta load: 'Squeak-dev image', (similarly for -funbeta -fullbeta -maxbeta -testbeta -seasidebeta -devbeta and -webbeta) ============

In our example, this action has a list of tasks that it depends upon, and these call up fixes from mantis. This fix tasks will apply themselves if they feel that they are contributing to the desired image.

self fixOneDay: '0000 Some bug not included, placeholder only'.

In this dummy example bug fix 0000 will never be loaded.

self fixUnstable: '1111 Some bug to be included in the Unstable Build of the next Release'.

Here 1111 will be loaded in tasks on "Unstable" classes e.g. ReleaseAfterSqueak310Unstable-c-taskTESTCANDIDATE

self fix: '2222 Some bug fix to be included in Next Release'.

Here 2222 will be loaded in tasks on "Unstable" classes e.g. ReleaseAfterSqueak310-c-taskTESTCANDIDATE

self fixEssential: '3333 Some bug to be included in any future Updates'.

Here 3333 will be loaded in tasks "Release" classes e.g. ReleaseSqueak310-c-taskUPDATE3 or ReleaseSqueak310-c-taskUPDATE1

==== dare I ask any questions?

Keith

I'd like to empasize this:

• Pharo has the clearly established nearly-achievable goals (good or

bad - depends on people's preferences)

• does Squeak has the same clearly established nearly-achievable goals?

If yes, then why they not on squeak.org, but on (http://installer.pbwiki.com/311)

Hi Igor,

We had a meeting with everyone that was interested perhaps 9 months ago.

Having re-iterated the goal, of more modularity, and better tools. It was agreed that the tools on their way at the time, particularly "MC2" (and now Sake) were likely to change the workflow to the extent that we were not in a position to establish any further goals beyond the "more modularity" and "better tools".

The rationale for this being that what is achievable with the old tools and the means to get there was likely to be entirely different with the new tools.

With this task based approach, you can make your own personal ideas for goals into tasks, and get started. When you are ready we simply include your task in the build. If the "release-team" dont like your task, or it is not ready for the mainstream, it may still be distributed with the release, for people to see what you were up to, and to contribute further to it. (roll on namespaces!?!)

The goals of 3.11 are mainly philosophical and social.

Technical goals currently on their way for 3.11 include:

* LevelPlayingField as standard (Monticello itself unload/loadable without losing essential state)

* Atomic Loading

* Traits as standard (but removable via unload task)

* Nail the package dependencies issue provide a mechanism to get all things working for everyone.

* Release a reasonably functional basic image (rather than a kernel image) but provide working unload tasks for non-essentials

* Remove a few more modules (but definitely ensure they are re-loadable)

* Removable tests (but definitely re-loadable)

* Ship with the very latest packages (3.10 shipped with out-of-date Installer/SqueakMap etc)

* Facilitate integration testing, the other side of the coin to image whittling and modularisation. i.e. be able to build and test a very full image.

* Bob the Builder for testing and image building, and one-click-image building

* Tidy up class organization

* Auto finalize the image, e.g. Readme, Release notes etc. version controlled (in mc)

+ "Fixes" as per usual (but automatically documented in verbose detail) we have about 90 so far.

Items marked with a + are specific to 3.11, items marked with a * are tasks which may potentially be applied to any 3.7+ image if you have been left behind or have been forced to fork.

Keith

* Traits as standard (but removable via unload task)

Peter Ahe of the Newspeak team at Cadence has written a script to remove traits from 3.9. If that's useful to you let me know and I'll find the code.

Matthew did the same a while back, hopefully its the same script :-)

Keith

"Igor Stasenko" siguctua@gmail.com writes:

2008/12/8 stephane ducasse stephane.ducasse@free.fr:

...

...

Hi,

Off Topic: Looks like there is debate stirring among the Ruby community on whether to fork Ruby to experiment with parallelization, etc. Sounds awfully familiar.

But forking is not the end, this is the start of something. Just have a look at what we are doing no MVC, no etoy, a lot of fixes, a lot of tests, TTF,.....

I'd like to empasize this:

• Pharo has the clearly established nearly-achievable goals (good or

bad - depends on people's preferences)

• does Squeak has the same clearly established nearly-achievable goals?

If yes, then why they not on squeak.org, but on (http://installer.pbwiki.com/311) , and also, why there is still people, like Edgar constantly attacking them, showing that there is no consensus about future of squeak?

So what's the point? Does anyone have to agree with another? I can not see that anyone is "responsible" for Squeak. So everyone does what he/she likes. I for my had my share of wishes also, but I can not see that many others share those. So bad for me, but Squeak still around and growing, so enough are quite happy with Squeak as it it these days.

I think, its important to define clearly, that EVERYONE should understand what is the current squeak goals, so no more discussions about them is needed. A clearly defined tasks is half of success.

A sure, we don't know what future will bring but we define it. Has worked remarkable well...

Regards Friedrich

On Dec 8, 2008, at 3:51 PM, Keith Hodges wrote:

Typically, about a month or so after 3.11 is released people will begin asking for an essential maintenance release of 3.10.x

This will be generated from the same set of fixes as used for 3.11, but only the fixEssential: fixes will be included.

This sounds very reasonable, logical and exciting. Thanks!

- TimJ