I have been thinking about what needs to be covered during my session at the language summit at PyCon which will cover 2.7/3.2 issues. One thing I have been wondering about is whether Python should consider shifting to a time-based release schedule. The rule of thumb has been that we do a minor release (e.g 2.7 is the next minor release for on the 2.x series) every 18 months.
To see if that 18 month idea was true, I created a chart (thanks to the Google Chart API for existing and Doug Napoleone for always hyping up the API). The x-axis is number of days and each section of the graph is the length of time to develop a micro release, although developing x.y.0 starts from the release of x.y-1.0 so that's why the initial values are so large.
It would seem that we are trending away from 18 months between minor releases rather quickly. While I would never propose a hard deadline (that's just stupid for open source when you are not trying to get a packaged piece of software done by a specific date for shipment), I wouldn't mind planning out release dates after the last minor release went out so we know when exactly stuff needs to get out (minus any bumps; see Python 3.1 and its planned 6 month release cycle).
The chart also points out some interesting things. One is that 2.3 was a trouble-maker. =) It has the most micro releases (2.30 through 2.3.5) on top of having the shortest amount of time between micro releases (10 days between 2.3.1 and 2.3.2 thanks to a bug). The 2.5 branch has been actively maintained the longest (4 years, 24 days from 2.4.0 to 2.5.4). And a random fact for myself: 2.2.3 was the first release which occurred while I had commit privileges.
