Note: the version numbering below is changing to date based versioning.
Releases to happen:
- 0.9.5, Target: 31st May 2009
- 0.9.7, Freeze: 6th July 2009, Target: 13th July 2009
- 0.9.9, Freeze: 7th Sept 2009, Target: 14th Sept 2009
- 0.9.11, Freeze: 2nd Nov 2009, Target: 9th Nov 2009
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:
- 1.0.2 - Probable Full Release, Freeze: 1st Feb 2010, Target release: 8th Feb 2010
- 1.0.4 - Freeze: 5th April 2010, Target: 12th April 2010
- 1.0.6 - Freeze: 7th June 2010, Target release: 14th June 2010
Reaching beyond that sort of timeline seems foolish, so I'm not going to try.
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:
- To make overall clearer & greater/clearer separation of:
- Merged of Chong's Google Summer of code project - 3D visualisation work (since this is something I actually need sooner rather than later)
- Flesh out http://www.kamaelia.org/Presentations somewhat...
- 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)
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.
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
- And future packaging changes automated, ideally. (enabling 0.7.0 easily)
- 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.
- Will better graphline shutdown help here?
- Start work on merging CAT with STM code
- Compatible with python 3.0 through a combination of using 2to3 and automated patches
- Requires a framework to be started to assist with this.
- 1.0.2 - Probable Full Release
Kamaelia 1.0 Release
- Axon 2.0 Release
- Python 3.0 compatible release (non alpha, non beta, actual 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
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
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:
- Y.Y.MM to be used as version number in 2009
Y.Y.MM to be used as version number in 2010
- 1.MM to be used as version number in 2011
- Y.MM to be used as version number 2012 - 2019(last digit of year only)
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