On Jun 26, 2009, at 8:49 AM, benjamin.peterson wrote:
Author: benjamin.peterson Date: Fri Jun 26 14:48:55 2009 New Revision: 73569 Log: update release candidate shorthand Modified: peps/trunk/pep-0101.txt Modified: peps/trunk/pep-0101.txt = = = = = = = = ====================================================================== --- peps/trunk/pep-0101.txt (original) +++ peps/trunk/pep-0101.txt Fri Jun 26 14:48:55 2009 @@ -66,7 +66,7 @@We use the following conventions in the examples below. Where a release number is given, it is of the form X.YaZ, e.g. 2.6a3 for Python 2.6 alpha- 3, where "a" == alpha, "b" == beta, "c" == release candidate. + 3, where "a" == alpha, "b" == beta, "rc" == release candidate.Final releases are named "releaseXY". The branch tag is "releaseXY-maint" because this will point to the long lived maintenance branch. The fork
I'm sure this has been discussed but I missed it. Why was this change made? If nothing else, it breaks many years of tradition.
-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
