No sooner do you put a new release out the door and you're reviewing things and planning the next. Since there seems to be a general trend towards numbering releases based on date rather than on (equally arbitrary) release numbers, we've decided to follow that trend. However, we've also planned to fill in the gaps to figure out how to manage shorter release cycles. Also, I don't want to artificially jump from version <1 to version 8, since it would very much say the wrong things.

When we hit version 1.0 I really want certain things in the system which aren't fully there yet, though most of the necessary spikes are in place). As a result, rather than using the versioning of YY.MM, we're going to move to using Y.Y.MM by the end of the year. That implies we hit version 1.0 in early 2010, which is actually only about 14/15 months off, so that seems reasonable. (hence the reason for switching to date based releases)

This means our next release will be 0.7.0, followed by 0.8.12. From then on we'll be moving to 6 weekly release candidate cycles, with a decision made at the beginning of each cycle whether that release candidate will be targetted as a full release, but there will definitely be release candidates. Given the delay between 0.5.0 and 0.6.0, jumping to a 6 weekly cycle seems challenging, so that's part of the reason for aiming for 2 releases by the end of the year (to get into the habit :).

As a result we're currently planning what's going into 0.7.0 now, with a planned feature merge freeze weekend 22nd November, and planned release date of weekend ending 30th Nov. That is intended to be followed up in late december by 0.8.12.

I've started a discussion on the mailing list about these, but the current planned focus for 0.7.0 follows.

• SuSE packaging for Axon & Kamaelia updated from 0.5.0 to K0.6.0 & A1.6.0
• And future packaging changes automated, ideally. (enabling 0.7.0 easily)
• Better graphline shutdown as discussed on the list.
• Tyson's extended version of the file appender,
• Merged of Chong's Google Summer of code project - 3D visualisation work (since this is something I actually need sooner rather than later)
• Packaging up of the whiteboard (pdf) as a standalone app
• Packaging up of the batch file processor (image/video transcoder) as a standalone app (or better packaging than this)
• A mirror of the Ben's Kamaelia AWS code into Kamaelia.Apps.AWS, if it's at a stage where it's ready. (aside from reviews etc)
• Merge of Jason's google summer of code on on extensions/improvements to the HTTP server code, including a better example of the seaside like functionality. (I think Kamaelia Publish itself should probably wait until 0.8.12 or 0.9.X) Probably after it gets a clearer name.
• 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)

Any suggestions and/or improvements or offers of help welcome :) Whether all this is doable in the time frame is a little speculative at present, but as the project's reaching maturity, it seems appropriate to take a more predictable approach towards releases, even if a release focus is "just" bug fixes, or documentation :)