Antoine Pitrou wrote: > Hello, > > Just food for thought here, but seeing how 3.1 is going to be a real > featureful > schedule despite being released shortly after 3.0, wouldn't it make sense to > tighten future release planning a little? I was thinking something like doing > a > major release every 12 months (rather than 18 to 24 months as has been > heuristically the case lately). This could also imply switching to some kind > of > loosely time-based release system. > > If I'm wildly off-base, you can either flame me, ignore me, or assign me > annoying release blockers involving memoryviews and weird character encodings > :-)
I don't think a shorter release cycle makes sense for a programming language. It's already the case that even with 18+ month release cycles some end users will leapfrog releases (e.g. 2.2-> 2.4 -> 2.6) for their environments (speaking from experience there, although the 2.6 part is mere wishful thinking at this stage). It also seems to takes 6-12 months for the complaints about Windows binary compatibility to die down after each release (although that appears to be less of an issue since MS released Visual Studio Express). That said, the 3.1 to 3.2 spacing will probably be shorter than normal (i.e. around 12 months), simply because 3.1 is an "extra" release to iron out some of the major issues with 3.0. This will give 'normal' 18 month spacing for the 2.6 -> 2.7 gap. The other big factor to consider here is the duration of bug fix support for releases. With our policy of "current release and previous release are supported with bug fixes" and the 18-24 month release cycle, that means each release typically receives bug fix updates for 3-4 years. That's a reasonably period of time (and gives plenty of time to shake out even fairly thorny issues). If we were to switch to yearly releases, then either the support policy would have to change to at least "current release and the previous two releases" or we'd have to accept the fact that the support period for each release would now be no more than 2 years. Since 2 years strikes me as an unacceptably short period for maintenance, shorter release cycles would then lead directly to having to maintain more parallel branches (which doesn't strike me as a good use of developer effort). Standardising a time frame for major releases is a fine idea, but I don't think shortening that time frame to 12 months would be wise. Settling on 18 months would probably work though - those that crave stability can then use every alternate version and only upgrade every 3 years, as each branch would be maintained with general bug fixes for at least 3 years and security fixes for a further 3 years after that. I think 24 months would lead to too slow an overall development tempo though - the year-and-a-half approach feels to me like it would strike a better balance. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
