Updates to pep 101 for GitHub-based releases
This commit is contained in:
Ned Deily
parent
e505618795
commit
76f6614ff0
114
pep-0101.txt
114
pep-0101.txt
|
|
@ -39,10 +39,9 @@ Things You'll Need
|
|||
and ``docs.iad1.psf.io``, the server that hosts the documentation.
|
||||
You'll be uploading files directly here.
|
||||
|
||||
* Shell access to ``hg.python.org``, the Python Mercurial host. You'll
|
||||
have to adapt repository configuration there.
|
||||
* Admin access to ``https://github.com/python/cpython``
|
||||
|
||||
* An administratior account on www.python.org, including an "API key".
|
||||
* An administrator account on www.python.org, including an "API key".
|
||||
|
||||
* Write access to the PEP repository.
|
||||
|
||||
|
|
@ -143,17 +142,14 @@ How to Make A Release
|
|||
|
||||
___ Make a release clone.
|
||||
|
||||
Create a local clone of the cpython repository (called the "release
|
||||
clone" from now on).
|
||||
|
||||
Also clone the repo at http://hg.python.org/cpython using the
|
||||
server-side clone feature. The name of the new clone should preferably
|
||||
have a "releasing/" prefix. The other experts will use the release
|
||||
clone for making the binaries, so it is important that they have access
|
||||
to it!
|
||||
|
||||
It's best to set up your local release clone to push to the remote
|
||||
release clone by default (by editing .hg/hgrc to that effect).
|
||||
On a fork of the cpython repository on GitHub, create a release branch
|
||||
within it (called the "release clone" from now on). You can use the same
|
||||
GitHub fork you use for cpython development. Using the standard setup
|
||||
recommended in the Python Developer's Guide, your fork would be referred
|
||||
to as `origin` and the standard cpython repo as `upstream`. You will
|
||||
use the branch on your fork to do the release engineering work, including
|
||||
tagging the release, and you will use it to share with the other experts
|
||||
for making the binaries.
|
||||
|
||||
___ Notify all committers by sending email to python-committers@python.org.
|
||||
|
||||
|
|
@ -166,7 +162,7 @@ How to Make A Release
|
|||
extra effort.
|
||||
|
||||
___ Make sure the current branch of your release clone is the branch you
|
||||
want to release from. (``hg id``)
|
||||
want to release from. (``git status``)
|
||||
|
||||
___ Check the docs for markup errors.
|
||||
|
||||
|
|
@ -188,7 +184,7 @@ How to Make A Release
|
|||
if there are differences, commit them.
|
||||
|
||||
___ Make sure the SOURCE_URI in ``Doc/tools/extensions/pyspecific.py``
|
||||
points to the right branch in the hg repository (or ``default`` for
|
||||
points to the right branch in the git repository (or ``default`` for
|
||||
unstable releases of the default branch).
|
||||
|
||||
___ Bump version numbers via the release script.
|
||||
|
|
@ -240,13 +236,14 @@ How to Make A Release
|
|||
|
||||
$ .../release-tools/release.py --tag X.Y.ZaN
|
||||
|
||||
NOTE: when forward, i.e. "null" merging your changes to newer branches,
|
||||
e.g. 2.6 -> 2.7, do *not* revert your changes to the .hgtags file or you
|
||||
will not be able to run the --export command below. Revert everything
|
||||
else but leave .hgtags alone.
|
||||
This executes a `git tag` command with the `-s` option so that the
|
||||
release tag in the repo is signed with your gpg key. When prompted
|
||||
choose the private key you use for signing release tarballs etc.
|
||||
|
||||
___ If this is a final major release, branch the tree for X.Y.
|
||||
|
||||
This section has not yet been updated for GitHub-based releases!
|
||||
|
||||
When making a major release (e.g., for 3.2), you must create the
|
||||
long-lived maintenance branch.
|
||||
|
||||
|
|
@ -303,9 +300,15 @@ How to Make A Release
|
|||
Also, update Doc/tools/templates/indexsidebar.html in all maintained
|
||||
branches.
|
||||
|
||||
___ Push your commits to the remote release clone.
|
||||
___ Push your commits to the remote release branch in your GitHub fork.
|
||||
|
||||
$ hg push ssh://hg.python.org/releasing/...
|
||||
# Do a dry run first.
|
||||
$ git push --dry-run origin
|
||||
$ git push --dry-run --tags origin
|
||||
# Make sure you are pushing to your GitHub fork, *not* to the main
|
||||
# python/cpython repo!
|
||||
$ git push origin
|
||||
$ git push --tags origin
|
||||
|
||||
___ Notify the experts that they can start building binaries.
|
||||
|
||||
|
|
@ -360,9 +363,9 @@ How to Make A Release
|
|||
___ Time to build the source tarball. Be sure to update your clone to the
|
||||
correct branch. E.g.
|
||||
|
||||
$ hg update 3.2
|
||||
$ git checkout 3.2
|
||||
|
||||
___ Do a "hg status" in this directory.
|
||||
___ Do a "git status" in this directory.
|
||||
|
||||
You should not see any files. I.e. you better not have any uncommitted
|
||||
changes in your working directory.
|
||||
|
|
@ -605,36 +608,53 @@ How to Make A Release
|
|||
|
||||
Now it's time to do some cleaning up. These steps are very important!
|
||||
|
||||
___ Temporarily disable others' pushes to the branch in the main cpython
|
||||
repo and bypass the normal status checks. Go to the
|
||||
Settings -> Branches page:
|
||||
|
||||
https://github.com/python/cpython/settings/branches/
|
||||
|
||||
and choose the Edit button for the branch you are working on.
|
||||
On the Branch Protection page, check the "Restrict who can push to
|
||||
this branch" box and add yourself. Also, uncheck the "Include
|
||||
administrators" box and save changes.
|
||||
|
||||
___ Merge your release clone into the main development repo:
|
||||
|
||||
# Pristine copy of the upstream repo branch.
|
||||
$ git clone --branch X.Y git@github.com:python/cpython.git merge
|
||||
$ cd merge
|
||||
# Fetch the newly created and signed tag from your repo
|
||||
$ git fetch --tags git@github.com:your-github-id/cpython.git vX.Y.ZaN
|
||||
# Null merge the temporary release branch discarding any changes
|
||||
$ git merge --edit --no-squash -s ours vX.Y.ZaN
|
||||
# Examine and update Misc/NEWS etc as needed. For example, you may
|
||||
# need to move NEWS entries for cherry-picked items.
|
||||
# Commit any changes.
|
||||
$ git commit -m '...'
|
||||
|
||||
___ Do the guided post-release steps with the release script.
|
||||
|
||||
$ .../release-tools/release.py --done X.Y.ZaN
|
||||
|
||||
Review and commit these changes.
|
||||
|
||||
___ Merge your release clone into the main development repo:
|
||||
|
||||
$ cd ../cpython # your clone of the main repo
|
||||
$ hg pull ssh://hg.python.org/cpython # update from remote first
|
||||
$ hg pull ../cpython-releaseX.Y # now pull from release clone
|
||||
|
||||
Now merge your release clone's changes in every branch you touched
|
||||
(usually only one, except if you made a new maintenance release).
|
||||
Easily resolvable conflicts may appear in Misc/NEWS.
|
||||
|
||||
___ If releasing from other than the default branch, remember to carefully
|
||||
merge any touched branches with higher level branches, up to default. For
|
||||
example:
|
||||
|
||||
$ hg update -C default
|
||||
$ hg resolve --list
|
||||
$ hg merge --tool "internal:fail" 3.4
|
||||
|
||||
... here, revert changes that are not relevant for the default branch...
|
||||
|
||||
$ hg resolve --mark
|
||||
|
||||
___ Commit and push to the main repo.
|
||||
|
||||
# Do a dry run first.
|
||||
$ git push --dry-run
|
||||
$ git push --dry-run --tags
|
||||
# If it looks OK, take the plunge. There's no going back from
|
||||
# this step!
|
||||
$ git push
|
||||
$ git push --tags
|
||||
|
||||
___ Undo the temporary changes to the GitHub settings for the branch.
|
||||
https://github.com/python/cpython/settings/branches/
|
||||
|
||||
Uncheck the "Retrict who can push to this branch". Check the "Include
|
||||
administrators" box and save changes.
|
||||
|
||||
___ You can delete the remote release clone, or simply reuse it for the next
|
||||
release.
|
||||
|
||||
|
|
@ -643,7 +663,7 @@ How to Make A Release
|
|||
|
||||
___ Update any release PEPs (e.g. 361) with the release dates.
|
||||
|
||||
___ Update the tracker at http://bugs.python.org:
|
||||
___ Update the tracker at https://bugs.python.org:
|
||||
|
||||
___ Flip all the deferred blocker issues back to release blocker
|
||||
for the next release.
|
||||
|
|
|
|||
Loading…
Reference in New Issue