On Sep 29, 2010, at 10:15 AM, Dirkjan Ochtman wrote: >Below is a grouped list. Based on that list, I propose the following >scheme: > >- keep all "normal" release tags, renamed along these lines: > r27 -> 2.7 > r266 -> 2.6.6 +1 > r27rc2 -> 2.7rc2 > r262c1 -> 2.6.2rc1 (rc and c should be normalized into the same >thing, don't care which one) Personally, I prefer 'c' to keep things regular. > r30b3 -> 3.0b3 > release22 -> 2.2 +1 >- keep Mac release tags that don't have the top-level Mac dir, renamed >along these lines: > r23b1-mac -> 2.3b1-mac +0 >- get rid of "special" release tags and Mac release tags with >top-level Mac dir >- get rid of email and distutils tags +0. If distutils-sig needs those tags, keep 'em. Similarly with email-sig, but being more involved with the separate email package releases, I don't think they'll be necessary. We're not going to diff against any earlier release and we have an email6 repository in Bazaar on Launchpad. When we integrate that back into Python, it'll likely be an undiffable change so I see no reason to keep the old tags (we can decide later if we'll want new tags in the main Python repo). >- get rid of all other tags +1. We'll always have the Subversion repository for the historical record. It'll make future mining a bit more difficult, but not insurmountably so and I'd rather plan for the benefit of future developers than the convenience of future archaeologists. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20100929/adf7d990/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