On Jul 3, 2009, at 6:15 PM, Martin v. Löwis wrote:
I'm fine with that plan - but the original problem remains. We willsurely release 2.6.4 at some point, and it will have a different versionidentification (based on hg rev ids).So those existing applications (which are probably few) will then crashfor 2.6.4, unless we continue maintaining 2.6 in subversion, or just arrange to fake sys.subversion somehow (e.g. freezing it on the last subversion revision - which might still break applications that insiston accessing the revision mentioned - not sure whether such applicationsactually exist).
Doesn't Mercurial support an Subversion bridge? Would it be possible to provide a /read-only/ copy of the hg branches for 2.4 (maybe), 2.5, 2.6, and 3.1? If so, then the release managers would simply have to cut their releases from the svn copy instead of the hg master. /All/ other work would be done from the hg master. This shouldn't be too much of a burden since it's done so rarely and would end with the EOL of each of those branches.
It would mean maintaining the bridge until all currently released versions are EOL.
If that's not possible or feasible, then given the documented sys.subversion semantics, I think we should just freeze the tuple at e.g. ('CPython', 'branches/release26-maint', None).
-Barry
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ 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
