iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update for new versioning scheme (3.3.0 instead of 3.3)

This commit is contained in:
Georg Brandl 2012-03-04 15:59:45 +01:00
parent c2924472b3
commit b3a0ba3f0e
1 changed files with 12 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
pep-0101.txt
View File

@ -62,11 +62,10 @@ How to Make A Release
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 @@ How to Make A Release
___ 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 @@ How to Make A Release
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 @@ How to Make A Release
___ 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 @@ How to Make A Release
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 @@ How to Make A Release
___ 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 @@ How to Make A Release
___ 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.