[Python-checkins] peps: Update for new versioning scheme (3.3.0 instead of 3.3)

[georg.brandl]

http://hg.python.org/peps/rev/3b2906825d96
changeset:   4112:3b2906825d96
user:        Georg Brandl <georg at python.org>
date:        Sun Mar 04 15:59:45 2012 +0100
summary:
  Update for new versioning scheme (3.3.0 instead of 3.3)

files:
  pep-0101.txt |  25 ++++++++++++-------------
  1 files changed, 12 insertions(+), 13 deletions(-)


diff --git a/pep-0101.txt b/pep-0101.txt
--- a/pep-0101.txt
+++ b/pep-0101.txt
@@ -62,11 +62,10 @@
         http://hg.python.org/release/
 
     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, "rc" == release candidate.  If a micro
-    release number is used, then we'll say X.Y.MaZ.
+    number is given, it is of the form X.Y.ZaN, e.g. 3.3.0a3 for Python 3.3.0
+    alpha 3, where "a" == alpha, "b" == beta, "rc" == release candidate.
 
-    Release tags are named "vX.YaZ".  The branch name for minor release
+    Release tags are named "vX.Y.ZaN".  The branch name for minor release
     maintenance branches is "X.Y".
 
     This helps by performing several automatic editing steps, and guides you
@@ -156,7 +155,7 @@
 
   ___ Bump version numbers via the release script.
 
-      $ .../release/release.py --bump X.YaZ
+      $ .../release/release.py --bump X.Y.ZaN
 
       This automates updating various release numbers, but you will have to
       modify a few files manually.  If your $EDITOR environment variable is
@@ -197,9 +196,9 @@
       alpha or beta releases.  Note that Andrew Kuchling often takes care of
       this.
 
-  ___ Tag the release for X.YaZ.
+  ___ Tag the release for X.Y.ZaN.
 
-      $ .../release/release.py --tag X.YaZ
+      $ .../release/release.py --tag X.Y.ZaN
 
   ___ If this is a final major release, branch the tree for X.Y.
 
@@ -309,10 +308,10 @@
   ___ Use the release script to create the source gzip and bz2 tarballs, md5
       checksums, documentation tar and zip files, and gpg signature files.
 
-      $ .../release/release.py --export X.YaZ
+      $ .../release/release.py --export X.Y.ZaN
 
       This will leave all the relevant files in a subdirectory called
-      'X.YaZ/src', and the built docs in 'X.YaZ/docs' (for final releases).
+      'X.Y.ZaN/src', and the built docs in 'X.Y.ZaN/docs' (for final releases).
 
   ___ scp or rsync all the files to your home directory on dinsdale.python.org.
 
@@ -361,7 +360,7 @@
       Python-3.2.tgz, along with a "prev" subdirectory containing
       Python-3.2a1.msi, Python-3.2a1.tgz, Python-3.2a1.tar.bz2, etc.
 
-      ___ On dinsdale, cd /data/ftp.python.org/pub/python/X.Y[.Z]
+      ___ On dinsdale, cd /data/ftp.python.org/pub/python/X.Y.Z
           creating it if necessary.  Make sure it is owned by group 'webmaster'
           and group-writable.
 
@@ -383,14 +382,14 @@
       ___ md5sum the files and make sure they got uploaded intact.
 
       ___ If this is a final release: Move the doc zips and tarballs to
-          /data/ftp.python.org/pub/python/doc/X.Y[.Z] creating the directory
+          /data/ftp.python.org/pub/python/doc/X.Y.Z creating the directory
           if necessary, and adapt the "current" symlink in .../doc to point to
           that directory.  Note though that if you're releasing a maintenance
           release for an older version, don't change the current link.
 
       ___ If this is a final release (even a maintenance release), also unpack
           the HTML docs to
-          /data/ftp.python.org/pub/docs.python.org/release/X.Y[.Z].
+          /data/ftp.python.org/pub/docs.python.org/release/X.Y.Z.
 
       ___ Let the DE check if the docs are built and work all right.
 
@@ -513,7 +512,7 @@
 
   ___ Do the guided post-release steps with the release script.
 
-      $ .../release/release.py --done X.YaZ
+      $ .../release/release.py --done X.Y.ZaN
 
       Review and commit these changes.
 

-- 
Repository URL: http://hg.python.org/peps