On May 12, 2009, at 6:06 PM, Antoine Pitrou wrote: > 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've been in favor of that for a while now. With the move to a DVCS (how's that coming along?) I think we can have more solid, releasable trunks for longer in the cycle. Then, we'd have feature branches which wouldn't land in trunk until they too are solid and complete (with docs and tests). If a particular feature doesn't make it, it'll just wait until the next release, which would be only 12 months off instead of almost 2 years off. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 304 bytes Desc: This is a digitally signed message part URL: <http://mail.python.org/pipermail/python-dev/attachments/20090512/ff440cdb/attachment.pgp>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4