April 2024 - This site, and Kamaelia are being updated. There is significant work needed, and PRs are welcome.

Development Roadmap

The path to Kamaelia 1.0


Note: the version numbering below is changing to date based versioning.

Releases to happen:

Beyond that date, this release schedule - which is based on "freeze on the first monday of every other month, and full release the following monday" - will probably need reviewing. If it seems appropriate, and if code has reached an appropriate stage, the release cycle will probably be this:

Reaching beyond that sort of timeline seems foolish, so I'm not going to try.

Feature Roadmap

Things that would be useful to go into releases... This section is a work in progress and will take time to dump out the various ideas people have had. Please bear with us and discuss this on the mailing list.

Overall aims:

Performance, Performance, Performance. Fibra shows that this is doable, and we should either match fibra, beat fibra, or join with fibra. (the last option is probably most fun :)

Frame work for enabling greater contribution - through Kamaelia.Apps.* namespace

Larger, more comprehensive examples - based around existing real world apps.

Website goals:


Perhaps initial work on integration of the STM code into the CAT. (The what? The STM and CAT tools were discussed at pycon uk) Though I suspect this will get started now, and merged in 0.8.12

2.6 cleanups (probably based on hinting from 2to3), and work started on a 3.0 autoconversion/build system.

Other stuff I'd like to see includes : work started on rationalising Kamaelia.File, Full review and merge of UDP_ng code in place of current UDP code, basic "connected" UDP server support (perhaps) (ie such that it can be used as a drop in replacement for TCPServer in ServerCore)

Better graphline shutdown as discussed on the list.

Tyson's extended version of the file appender,

SuSE packaging for Axon & Kamaelia updated from 0.5.0 to K0.6.0 & A1.6.0

Nanowrimo examples! & results of Nanowrimo example writing...

Merge of other Summer of code projects.

Probably Dave's paint program

Rest of Jason's code, esp WSGI support

Start scavenging Joe's project for mergeable components.

Could consider merging code from Pablo's abortive planet code, since may have useful scavengeable code.

Start extracting Matt's testing framework from graphline tests, to see what we can do.

Start work on merging CAT with STM code

Aim to have started the path to python 3.0. (hence 0.9.3 would hopefully be alpha quality python 3.0

Would be nice to have a Threaded* Chassis - for taking normal Kamaelia components and slinging them into seperate threads.


1.0.2 - Probable Full Release

Other Aspiration Features

If you want to add features you'd like to see, please add to this thread on the mailing list, we can then reference the thread back here for discussion purposes. PLEASE remember to replace "Your Idea" in the subject line with your feature idea!

Possible Questions, Answers

Version numbers.

Kamaelia's version number is pre-1.0 for good reasons (as of Nov 2008) - there are specific things that (at least) Michael would like to see in a full version 1.0. However, many projects are switching to a more date based approach. Since we figure that we're about a year away from being "feature complete" in Kamaelia (in terms of graphical creation tools, full set of appropriate chassis, potential for shard support, etc) it seems reasonable to switch to a versioning of Y.Y.MM.

This is the reason for 2 releases before the end of the year - 0.7.0 being the next logical one after 0.6.0, and the one after 0.7.0 being 0.8.12, with 0.8.12 being the first release matching the new versioning scheme.

If the project keeps running then, then I would also expect the following:

It seems really odd to be planning version numbers that far out, but it's worth realising the first release of Kamaelia was in 2004, so 2012 is the same timeframe (or so) forwards. Not only that, but Kamaelia's model does seem to have longevity.

Timing? 6 Weeks? Bi-Monthly?

These target dates are deliberately far enough to be doable, but not so far that the planning for each stage to become unrealistic. Also, they're specifically designed to prevent "mega" releases being planned with "one more thing" preventing actual release.

-- Last updated November 2008

That didn't work. Shifting to 2 monthly cycles instead, since it feels more "humane" :-)

-- May 2009

As of the 0.6.0 release the project is moving through a transition stage.

Future releases will be based on a bi-monthly release cycle, with version numbers based on dates, rather than arbitrary(!) version numbers.