[Python-checkins] peps: Simplify PEP 101 a bit; remove instructions for "prev" directory.

[georg.brandl]

http://hg.python.org/peps/rev/74bd49748c0a
changeset:   5369:74bd49748c0a
user:        Georg Brandl <georg at python.org>
date:        Sun Feb 09 10:27:17 2014 +0100
summary:
  Simplify PEP 101 a bit; remove instructions for "prev" directory.

files:
  pep-0101.txt |  74 +++++++++++++++------------------------
  1 files changed, 29 insertions(+), 45 deletions(-)


diff --git a/pep-0101.txt b/pep-0101.txt
--- a/pep-0101.txt
+++ b/pep-0101.txt
@@ -380,29 +380,15 @@
 
   ___ Now you need to go to dinsdale.python.org and move all the files in
       place over there.  Our policy is that every Python version gets its own
-      directory, but each directory may contain several releases.  We keep all
-      old releases, moving them into a "prev" subdirectory when we have a new
-      release.
-
-      So, there's a directory called "3.2" which contains Python-3.2.msi and
-      Python-3.2.tgz, along with a "prev" subdirectory containing
-      Python-3.2a1.msi, Python-3.2a1.tgz, Python-3.2a1.tar.bz2, etc.
+      directory, but each directory may contain several releases.
 
       ___ 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.
 
-      ___ Move the previous release files to a directory called 'prev'
-          creating the directory if necessary (make sure the directory has
-          g+ws bits on).  If this is the first alpha release of a new Python
-          version, skip this step.
-
-          For pre-releases (alpha, beta, rc), don't move things into a 'prev'
-          directory, You'll move everything in there when the final release
-          comes out.
-
-      ___ Move the release .tgz, tar.bz2, .tar.xz, .dmg and .msi files into
-          place, as well as the .asc GPG signature files.
+      ___ Move the release .tgz, and .tar.xz files into place, as well as the
+          .asc GPG signature files.  The Win/Mac binaries are usually put there
+          by the experts themselves.
 
           Make sure they are world readable.  They should also be group
           writable, and group-owned by webmaster.
@@ -421,9 +407,6 @@
           If it is a release of a security-fix-only version, tell the DE to
           build a version with the "version switcher" and put it there.
 
-      ___ For branches out of maintenance: adapt the symlink in
-          /docs.python.org/release/X.Y to point to the recent version.
-
       ___ Let the DE check if the docs are built and work all right.
 
       ___ If this is a major release: Tell the DE to adapt redirects for
@@ -479,8 +462,29 @@
       existing recent directory and twiddle the files in there for the new
       version number.
 
-  ___ Add a news section item to the front page by editing newsindex.yml.  The
-      format should be pretty self evident.
+  ___ Update the version specific pages.
+
+      ___ cd to `download/releases/X.Y.Z`
+      ___ Edit the version numbers in content.ht
+      ___ Update the md5 checksums
+
+      ___ Comment out the "This is a preview release" or the "This is a
+          production release" paragraph as appropriate
+
+      ___ Update the license in `download/releases/X.Y.Z/license`
+
+      Note, you don't have to copy any release files into this directory;
+      they only live on dinsdale in the ftp directory.
+
+  ___ Edit `download/releases/content.ht` to update the version numbers for
+      this release.  There are a bunch of places you need to touch:
+
+      ___ The subdirectory name as the first element in the Nav rows.
+      ___ Possibly the Releases section, and possibly in the experimental
+          releases section if this is an alpha, beta or release candidate.
+
+  ___ Update the download page, editing `download/content.ht`.  Pre-releases are
+      added only to the "Testing versions" list.
 
   ___ If this is a final release...
 
@@ -496,28 +500,8 @@
 
       ___ Add the new version to `doc/versions/content.ht`.
 
-  ___ Update the download page, editing `download/content.ht`.  Pre-releases are
-      added only to the "Testing versions" list.
-
-  ___ Edit `download/releases/content.ht` to update the version numbers for
-      this release.  There are a bunch of places you need to touch:
-
-      ___ The subdirectory name as the first element in the Nav rows.
-      ___ Possibly the Releases section, and possibly in the experimental
-          releases section if this is an alpha, beta or release candidate.
-
-  ___ Update the version specific pages.
-
-      ___ cd to `download/releases/X.Y.Z`
-      ___ Edit the version numbers in content.ht
-      ___ Comment out the link to the CHM file if this is not a final,
-          remove the comment if it is.
-      ___ Update the md5 checksums
-
-      ___ Update the license in `download/releases/X.Y.Z/license`
-
-      Note, you don't have to copy any release files into this directory;
-      they only live on dinsdale in the ftp directory.
+  ___ Add a news section item to the front page by editing newsindex.yml.  The
+      format should be pretty self evident.
 
   ___ When everything looks good, `svn commit` in the data directory.  This
       will trigger the live site to update itself, and at that point the

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