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
signature.asc
Description: PGP signature
_______________________________________________ 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
